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ABSTRACT 

This thesis describes the complete development process of a fully functional 
Intranet for an operational United States Coast Guard (USCG) Electronic Support Unit 
(ESU) in Alameda, California. The final product is suitable for immediate use. It may 
also be used as a prototype for future Intranet development efforts. 

The methodology used to develop a finished, working product provides the core 
subject matter for this thesis. The discussion will concentrate on why certain applications 
were developed, how they are intended to be used, and what business benefits they 
provide. 

The Intranet was developed in seven unique stages of the Waterfall Model of 
information systems design. The Waterfall Model traces a systems development lifecycle 
from planning, to logical design, through physical design, and finally ends with the 
implementation process. Each stage of the development model is addressed in this thesis. 

Intranet technology provides a radical new means of communicating throughout 
an organization. This new technology has the potential to change the organization. 
Elaboration on both the social and technical aspects of introducing an information 
systems change to the ESU is included. 
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I. BACKGROUND 



A. INTRODUCTION 

This thesis describes the complete development process of a fully functional 
Intranet for an operational United States Coast Guard (USCG) Electronic Support Unit 
(ESU) in Alameda, California. The final product may be used as an operational Intranet 
for the ESU, or it may simply be a prototype, which can be used as a baseline for future 
development efforts. 

The Intranet was developed in seven unique stages of the Waterfall Model of 
information systems design. The Waterfall Model traces a systems development lifecycle 
from planning, to logical design, through physical design, and finally ends with the 
implementation process. Each stage of the development model is addressed in this thesis. 

The development effort resulted in a complete physical product, which will be 
delivered to the customer. The discussion will concentrate on how and why certain 
applications were developed, how they are intended to be used, and what business 
benefits they provide. Both the management aspects and the technical solutions for the 
Intranet vrill be addressed. 

Intranet technology provides a radical new means of communicating throughout 
an organization. The product of this thesis is a well designed and technically solid, 
Intranet tool with significant potential to enhance, improve and eliminate current ESU 
business processes. This new technology has the potential to change the organization. 

The final success or failure of the implementation does not depend solely on the 
technical merits of the system. Instead, the social aspects of introducing a powerful new 
information system to an organization must be considered. The way the change is 
managed will determine the final outcome of the implementation process. The results of 
the new change will not be known for some time. 

B. CUSTOMER 

The sponsoring Command was United States Coast Guard Electronic Support 
Unit Alameda (ESU). ESU Alameda’s mission is to provide support and maintenance 
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resources for all electronics, telecommunications and computer equipment aboard USCG 
units in the Eleventh Coast Guard District. The Eleventh District encompasses the entire 
State of California as well as any USCG units requesting assistance while in California 
waters. The ESU has a central office located in Alameda, California where there are 
about 50 full time employees. ESU Alameda also has three remote ESU Detachments 
which are located in San Pedro, San Diego and Oxnard, California. 

C. OBJECTIVE 

The thesis objective is to build a functional prototype Intranet. The customer may 
find many different ways of using it. The possible outcomes from the implementation 
process are listed here in order of increasing success. First, the Intranet may be 
considered solely as a prototype, which demonstrates the capabilities of Intranet 
technologies. In this case, it would rarely be used in daily operations. Next, the Intranet 
may actually be integrated and used in the ESU’s daily operations as a fully functional 
tool. Finally, it may be both an operational tool as well as a prototype that is maintained 
and enhanced at the ESU. This foundation of an Intranet may grow larger over time as the 
ESU takes ownership of it. This is the ideal goal. 

In all cases, the ESU will benefit from this thesis. Their Intranet is custom built 
with over 80 dynamically generated pages. A commercial Web site costs a minimum of 
$1000 for a basic site, designed from template, with a maximum of 20 static pages 
(www.Interland.net). The ESU Intranet is essentially free. Even if the Intranet 
implementation fails over the long term, the ESU will have had a working prototype to 
test. This will give them an advantage on any future Intranet requirements determination 
cycle. They will have had a more comprehensive understanding of their own needs and 
the capabilities of the technology. 

D. INTRANET DEFINED 

An Intranet is simply a private version of the Internet. Intranets conveniently 
make internal company information available to all employees using the same protocols 
and technologies that make the World Wide Web so successful. Where the Internet is 
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global in reach, an Intranet is private and usually access is either physically or virtually 
restricted to a particular company’s members. An Intranet opens the channels of 
communication to allow sharing, updating and querying for information throughout the 
network without regard to time or distance. 

The minimum requirements for an Intranet include a local area network, a Web 
Server, Web browsers, and Web authoring tools. Intranet information is typically 
displayed on Web pages in a client terminal’s Web browser window. 

E. INTRANET OBJECTIVE 

The objective of the Intranet is to provide a technology tool that will add value to 
the ESU’s daily operations. The Intranet is a tool that should be incorporated into a 
broader organizational management plan. 

The goal of the developer was to address the Command’s top needs with Intranet 
solutions. Analysis of the ESU’s business model uncovered many business processes, 
which could benefit from Intranet technologies. Choices had to be made about which 
applications were most feasible and which would actually be developed for the ESU 
Intranet. Availability of technology, the author’s expertise, and time constraints were 
limiting factors that narrowed the scope of applications development. The final product 
successfully addresses aspects of two major concerns of the ESU Command, personnel 
administration and supply tracking. Other business benefits, such as remote availability 
of up-to-the minute dynamic information and enhanced communications across the 
organization, were also realized. 

F. METHODOLOGY 

The goals of the project were both to develop an actual working product and to 
design a prototype that demonstrates the capabilities of the technology. The Waterfall 
Model or Systems Development Lifecycle (SDLC), with its process of clearly defined 
steps, was used to develop the working Intranet product. The Waterfall Model approach 
was helpful in structuring the development progress from requirements analysis at the 
start until final implementation at the ESU by the end. 
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G. INTRANET DESIGN AND APPLICATION FEATURES 

The project design incorporates two partitions labeled “Intranet” and “Extranet”. 
“Intranet” information is protected by security access levels and authorized users are 
specifically limited to ESU employees use only. “Intranet” information includes access 
to persormel and supply databases and the ability to execute Intranet applications that take 
their data from those databases. “Extranet” information is available to anyone who is on 
the Coast Guard Data Network Web (CGWEB). The CGWEB, as defined in USCG 
Commandant Instruction 5230.57, uses Internet technology inside the USCG security 
perimeter (users behind USCG firewalls) to provide a “private Internet”. ESU “Extranet” 
information includes a phone and e-mail directory, access to other ESU Alcuneda 
department Web sites, and the daily list of who is on leave or away for temporary duty. 

Security is implemented on a page by page basis. When a page is requested, the 
security access level is checked and access is granted or denied based on the access level 
the user has logged in at. 

On-line form processing is a significant application feature on the Intranet. Forms 
that were once filed and routed through office inboxes and outboxes can now be 
instantaneously routed through virtual inboxes and outboxes. The form data is 
automatically stored in databases. This provides new ways to query and manipulate data 
that was once only stored in filing cabinets or not at all. 

The site design is generic enough to be installed at other Coast Guard units. Once 
ESU Alameda tests the Intranet and fine tunes it, it could possibly be deployed to other 
local cormnands, to other ESU’s or any other Coast Guard units. 

The Leave, Temporary Assigned Duty (TAD), and Recall Log are three 
applications that support the ESU’s priority of keeping better track of personnel. The 
Marks Application supports the Command’s goal of forecasting when personnel marks 
are due. The Supply Application introduces on-line form processing and status updates 
for Purchase Requests. This supports the ESU’s interest in improving the supply 
ordering processes. The Announcements Application facilitates better commimications 
throughout the ESU. The Phonebook Application provides “Extranet” visitors with up- 
to-date phone numbers and email addresses. 
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H. INTRANET IMPLEMENTATION 

The Intranet will be installed at the ESU during the summer of 1998. There are 
many issues of managing social and technical change which could affect the complete 
adoption of a new tool like an Intranet. 

In order for the ESU to take ownership for and maintain their new Intranet site, 
both the management solutions and the technical solutions must be addressed during 
implementation. From the business perspective, the ESU will have to write their own 
policy on Intranet use to include guidance on security, acceptable use instructions and 
backups. Recommendations on change management, or how to introduce a new 
information system to an organization, were included as part of this thesis. Technical 
details of the Intranet were included in this thesis as well. 

I. CONTENTS 

This section contains a brief summary of the thesis chapters. 

1. Chapter I. Background 

This chapter introduces the thesis topic, customer and a brief definition and 
discussion of the Intranet, its applications and implementation issues. 

2. Chapter II. Intranet 

This chapter introduces terms used throughout the thesis. Discussion in this 
chapter focuses on what an Intranet is, how it can affect an organization, and the technical 
requirements for implementing one. 

3. Chapter III. Limitations and Assumptions 

This chapter describes the limitations and assumptions that affected decisions 
about what Intranet applications were actually developed for the ESU. 

4. Chapter IV. Methodology 

The Intranet development and design methodology is described in this chapter. 
The stages of the Waterfall Model are defined here. Discussion of how each stage was 
conducted is presented in this chapter. The Rapid Prototyping model is also defined here. 
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5. Chapter V. Analysis 

Analysis of ESU Alameda’s business model is covered in this chapter. The 
criteria for selection of business processes for Intranet solutions are described here. 
These criteria drove Intranet development. The chapter finishes with a logical design of 
an ESU Intranet. 

6. Chapter VI. Software Tools 

This chapter identifies what software tools were used for developing the Intranet. 
The reasons why these tools were chosen are explained here. 

7. Chapter VTI. Physical Design 

A brief tutorial of how to physically build an Intranet is provided in this chapter. 
The guiding principles, such as the Graphic User Interface, behind hundreds of hours of 
code and development effort are discussed in this chapter. 

8. Chapter VIIL The Applications 

The applications are the final products from the physical design phase. This 
chapter details each specific Intranet application and how it is meant to be used. Screen 
shots of each relevant Web page of the applications are included. 

9. Chapter IX. Implementation 

This chapter covers implementation primarily from a management perspective. 
The idea that it is the social aspect, not solely the technical, that determines the outcome 
of an information systems change in an organization is discussed in this chapter. An 
organizational change formula is also presented here. 

10. Chapter X. Conclusion 

This chapter contains the conclusion. A look to the future for further development 
ideas and lessons learned are also presented here. 

11. Appendix A: ASP Application Design and Code 

The appendix contains a short explanation of how Active Server Pages were used 
to implement the Announcements Application on the Intranet. The on-line 
announcements form queries the user for information, updates the database, and displays 
a result. These interactions are typical and foimd in most of the applications across the 
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Intranet. The HTML, Visual Basic Script and ASP code listings are presented in both a 
visual context as well as textual. 

12. Appendix B: Glossary of Terms 

This glossary is reprinted from various on-line services. It provides the thesis 
reader with the definitions of some of the technical terms used throughout the thesis. 

13. Enclosures 

The source code for the thesis is contained on a CD-ROM disk. This disk 
contains a folder named "prototype2" with all the Web pages of the Intranet site. This 
folder may be copied to the WWWROOT directory of any Windows Internet Information 
Server, running Active Server Pages, for an instant Intranet. A "ReadMe" file is included 
to address the specifics of installation. The disk contains three Access databases named 
"phonebook", "supply", and "armouncements". The text of this thesis is also on the CD- 
ROM. (Note that this CD-ROM is not included with all copies of this thesis. It can be 
checked out from the Dudley Knox Library at NPS.) 
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II. INTRANET 



A. INTRODUCTION 

An Intranet opens the channels of communication to allow sharing, updating and 
querying for information throughout the network without regard to time or distance. This 
chapter briefly defines what an Intranet is, what benefits may result from having one, and 
how it works. Discussion of the ESU Intranet is also included here. 

B. INTRANET DEFINED 

An Intranet adapts the technologies used on the World Wide Web for use on an 
internal network. In essence, it is a private Internet. An Intranet uses a client-server 
model. This means it is run from a central Web server with client computers accessing it 
through Web browsers. 

The reference to “ESU Intranet” throughout the thesis primarily refers to the 
actual Web pages the end-user sees in their Web browser window. In reality, the scope of 
the ESU Intranet is broader and it includes all the underlying components and code 
necessary to run the client-server Intranet site. When a client computer makes a request 
on the Intranet, these components allow back-end databases to feed data to the Web 
server. The Web server then dynamically generates Web pages, from the results of the 
database query, and outputs the pages to client Web browser that made the request. 

To develop and maintain an Intranet, the minimum requirements include a 
Transmission Control Protocol/Intemet Protocol Local Area Network (TCP/IP LAN), a 
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Web server, Web browsers, and Web authoring tools. Intranet information is typically 
displayed on Web pages in a client terminal’s Web browser window. 



C. INTRANET BENEFITS 



There are numerous benefits to an Intranet. The essence of it is that more 



information is available to more people in a common, accessible format. An Intranet is 



“... a TCP/IP network inside a company that links the people and 
information in a way that makes people more productive, information 
more accessible, and navigation through all the resources and applications 
more seamless than ever before.” (p.57, Burleson, 1994) 
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Figure 2.1 Intranet Benefits and Challenges (CIO Insider) 

These common applications usually are the first to be implemented on a new 
Intreinet. Initially, they tend to demonstrate the capabilities of the new technology and 
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often have an immediate and dramatic impact on the organization. The applications 
include: 

• phone directories 

• employee information 

• company policies 

• product information 

• training information 
Other powerful applications include: 

• database interactions 

• groupware 

• knowledge capture 

• decision support 

Remote access to the Intranet is possible through a common, platform 
independent, interface. Platform independence means that even clients running different 
operating systems on different kinds of computers can access the Intranet. For example, 
an Intranet that is hosted on an Intel Pentium-based computer running Microsoft NT 
Internet Information Server can be accessed by Sun Solaris UNIX-based computers or 
even Macintosh clients. Any computer capable of running a Web browser, that has a 
cormection to the Intranet network, can access the Intranet and its Web enabled databases. 
The Web browser takes the place of a traditional application specific interface. 
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These and other Web-enabled applications have the power to change an entire 
organizational environment by “making information, once buried in hundreds of places in 
the organization, available to everyone” (pp. 15-16, Burleson, 1994). 

D. INTRANET SCOPE 

An Intranet’s scalability is virtually unlimited since it uses the same technologies 
that make the global World Wide Web possible. One of the most powerful features of an 
Intranet is access to enterprise-wide information without regard to time or distance. The 
term “enterprise” means the entire organization. For example, the Ford Motor Company 
Intranet could provide employee benefits information to all of its employees worldwide 
through an enterprise wide Intranet. 

The U.S. Coast Guard is the enterprise with regard to the ESU Alameda Intranet. 
The USCG enterprise wide Intranet is currently under construction on the Coast Guard 
Data Network Web (CGWEB). The CGWEB, as defined in USCG Commandant 
Instmction 5230.57, uses Internet technology inside the USCG security perimeter (users 
behind USCG firewalls) to provide a “private Internet”. 

Any USCG employee who has access to the CGWEB will be able to access the 
ESU Alameda Intranet. This gives the ESU the power to update its own information, 
such as its phone directory, and the change is immediately reflected and available 
throughout the enterprise. 

Not all Intranet information is appropriate for enterprise wide distribution. 
Payroll or financial data, for example, should not be distributed as widely as phone 
directory information. An Intranet typically will have internal and external customers. 
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The ESU Intranet is modeled with two distinct Intranet areas. Information posted on the 
ESU “Extranet” is available enterprise vvade to anyone with access to the CGWEB. The 
ESU “Intranet” data is only available to ESU employees and access requires a login and 
password check. 

E. HOW INTRANETS WORK 



1. Client-Server Model 

The client-server model is very simple. One computer on a network, the server, 
acts as a central processor for a group of client computers. The server is dedicated to 
responding to requests from client computers. For example, an application server would 
host a shared application, such as a word processing program, which could then be 
executed on any client computer on the network. 



Client-Server Model 




Clients 



Figure 2.2 Client-Server Model 

A Web browser and Web server emulate the client-server information systems 
model. The Web server on the ESU Intranet responds to requests from clients by 
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querying its databases and then dynamically generating Web page code. The Web server 
returns the code to the client’s Web browser window. 

The ESU Intranet client-server models work with a middleware component that 
facilitates the interaction of the databases with the Web browser. The Web server hosts 
the Intranet site by generating and serving HTML code to the client Web browsers upon 
request. The database holds all the relevant data for Intranet applications. 

2. Network 

The ability to have an Intranet depends on having computers that can 
communicate wnth each other. If two computers want to exchange data, they must speak 
the same language. Transmission Control Protocol/Intemet Protocol (TCP/IP) is the 
protocol, or common network language, that allows computers to exchange data. There 
are other protocols available, but TCP/IP is the one used to transmit data across the 
Internet. It is such a versatile language that data can be sent from one computer, routed 
over the Internet, and arrives across the globe just as it was sent. 

3. Static and Dynamic Web Pages 

Typical Web pages are static documents, which means that they do not change. 
Static pages are written once and served to the client’s Web browser in Hypertext Markup 
Language (HTML) code. For example, a Web page that contains the text of the 
Constitution of the United States would be static because the HTML code could be 
■written once and then never (or rarely) need to be changed. 
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Most of the Web pages on the ESU Intranet are different because the pages are 
dynamic. The HTML code for a dynamic Web page is individually recreated on the Web 
server every time a client browser requests a page. This is called “server side scripting” 
because the server rewrites every HTML page at the server before passing it to the client. 
For example, a Web page that displays the results of an Web search on the keyword 
“constitution” would be dynamic because the Web server would have to generate a new 
and unique response, in HTML for the client, specifically on that keyword search. 

F. INTRANET APPLICATIONS 

1. Web browser as Application Interface 

The traditional view of an application is that it is a standalone program that is 
launched with its own uniquely developed human to computer interface. With a Web 
enabled Intranet application, the user can navigate through an application with a 
customized interface created for the Web browser. While there are certainly limitations 
with what one can accomplish visually in a Web browser window, there is a huge benefit 
in that every single Web-enabled application can be launched through the same human to 
computer interface window. 

For example, in a traditional Microsoft Access database application, the user 
navigates the database through either the default Access interface or a customized 
interface created by the developer from within Access. Either way, the user is still 
running the database through the Access application program. The Intranet view of the 
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application is always through the Web browser. In fact, on the Intranet the Access 
application program is never launched or even seen by the user. 

2. Other TCP/IP Applications 

Applications and other protocols “ride” on top of TCP/IP. Although the Web 
browser, which uses the HyperText Transport Protocol (HTTP), is the most common 
Intranet application, any program that can use TCP/IP can be implemented across an 
Intranet network. Other useful applications include e-mail and video teleconferencing. 

3. ESU Intranet Applications 

Applications on the ESU Intranet are defined as groups of interrelated, dynamic 
Web pages that interact with a back-end database. The Web browser window is the 
standard interface for all ESU Intranet applications. 

G. CONCLUSION 

An Intranet is a powerful tool that is reshaping the way people communicate 
throughout the enterprise. It has tangible benefits, it is fairly easy to deploy, and just as 
the Internet’s growth is seemingly unlimited, an Intranet’s scalability is virtually 
unrestricted. There are also countless challenges, such as maintaining current content, 
and consequences, such as changing existing business processes, of using this new 
technology. 

The rest of this thesis will explore these challenges and consequences of turning 
the idea of an Intranet into a reality for a mid-sized USCG unit. Designing the product. 
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aligning the technology with the unit’s business goals, and successfully introducing a 
change will be covered. 
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III. LIMITATIONS AND ASSUMPTIONS 



A. INTRODUCTION 

The author faced limitations of competency and technical skill and made 
assumptions for this project. Choices, which affected the ultimate design of the system, 
were governed, in part, by these factors so discussion of them is warranted. 

B. INTRANET DEVELOPMENT ASSUMPTIONS 

1. Introduction 

The focus of this thesis is on the complete process of Intranet systems 
development. This thesis concludes with an actual physical product that is ready for 
operational testing and daily use. 

2. Qualifications 

The scope of thesis had to be narrowed to a practical and attainable goal. This 
means that choices had to be made about which processes would be modeled and what 
priority they would take. The abilities of the author were a significant factor in which 
choices were made for the final product. For that reason, some discussion of what those 
abilities are and how they were acquired is relevant. 

Qualifications to undertake this project were acquired over eighteen months of 
classroom instruction and self-study in the Naval Postgraduate School’s Information 
Technology Management curriculum. The curriculum covers many methodologies and 
theories of the logical process of information systems analysis, design, development and 
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implementation. The management aspects of introducing information system change to 
an organization are also covered in this curriculum. 

The technical aspects of developing code and choosing appropriate software tools 
for the physical design of the Intranet were mainly learned through self-study. The tools 
and applications that were learned during the four-month development phase included 
various Web site design tools, database applications, Internet servers, middleware. Visual 
Basic script and JavaScript programming languages. A method for learning these tools 
included consulting many books, tutorials, on-line guides, trade journals, Internet 
resources and resorting to serendipitous trial and error. A proficiency, but not expertise, 
in all of the critical areas was attained. 

3. Coast Guard Perspective 

Being a United States Coast Guard officer, the author had relevant experience, 
which provided a foundation for analyzing the needs and processes of a USCG unit. This 
USCG background had natural advantages for requirements analysis. It also led to some 
assumptions of how a USCG unit should look. A USCG consultant working for a USCG 
customer does face the danger of simply automating existing business processes instead 
of re-thinking them in fresh new ways. The author was conscious of this possible bias. 

4. Remote Development Site 

Although there was a comprehensive analysis of the ESU’s business model, the 
Intranet developer will not use the ESU Intranet on a day to day basis. The Intranet was 
not created on site in the true ESU Alameda working environment. Instead, it was 
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developed remotely at Naval Postgraduate School. This offered the advantage of a fresh 
perspective. There is, however, a danger that some aspects of the ESU business model 
were missed which may affect the chances of long term Intranet success. 

5. Resource Constraints 

Naval Postgraduate School, not the thesis customer, provided almost all of the 
resources necessary to complete the project. These resources included access to a 
Windows NT server class computer, a dedicated Internet Protocol address registered with 
the InterNic Domain Name Service as “cg.nps.navy.mil”, and various software 
development tools. 

Money played a role in the selection of software development tools. The sponsor 
had limited funds and only agreed to pay for a few days of thesis travel and one technical 
book. The sponsor purchased one $50 software component which was required, but was 
unwilling to spend a significant amount of money for new, non-Coast Guard standard 
software for a research project. A primary criterion for selection of software tools was 
therefore price and academic availability. 

Since the science of and tools for Intranet development are relatively new, there 
are few books and references in the NPS library. Most of the books and relevant 
reference material had to be purchased or looked up on-line over the Internet. Technical 
books on Intranets and software generally cost $60 to $100. Aside from the one technical 
book the customer purchased, all other relevant technical books were borrowed from NPS 
or purchased individually. This constraint meant the developer was highly selective in 
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which tools to attempt to learn. Buying the books to learn too many different software 
tools was prohibitively expensive. 

6. Assumptions 

Assumptions made for this project affected the development and outcome of it in 
various degrees. A brief list of these assumptions follows. 

The biggest assumption was that ESU Alameda actually wanted a new Intranet 
developed as part of an NFS thesis. The Intranet idea was proposed from the author to 
the customer, not the other way around. Also, it was assumed that the thesis would not be 
funded to the degree of other projects whose sponsors have specific research goals or 
agendas. Since the Intranet proposal did not come from within the ESU, it was assumed 
that some employees of the unit would resist the change the new Intranet introduces. 

A belief that Intranet technologies could improve, enhance or re-engineer existing 
aspects of the ESU Alameda business model was also presupposed. Finally, it was 
assumed that the project was feasible. There was a faith that acquiring the technical skills 
and qualifications to see the project through to completion was possible. 

7. Technical Ability Bias 

The lack of a comprehensive technical expertise may have introduced bias into the 
selection of business process Intranet applications to develop and the software tools to 
design with. Inexperience may have prevented an entirely critical evaluation of the 
variety of Intranet software development tools available. A bias towards picking 
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software tools that were the easiest to use and learn, and a tendency to choosing the least 
complex business processes for application design, occurred in this project. 

8. Time Constraint 

Ideally, the author would have liked to create a more comprehensive Intranet site 
for the customer. The site would contain more applications for more Web enabled 
business processes. There would be rich content organized by knowledge area, more 
decision support tools would be available and easy content development applications 
would be used on the Intranet to empower all members of the organization to 
communicate in new ways. In reality, the most significant constraint that stood in the 
way of such a comprehensive effort was that there simply was not enough time. 

C. CONCLUSION 

Despite these biases, constraints, and assumptions, the final product works and 
meets many of the ESU’s goals and needs. This Intranet may yet be the seed of a new 
USCG information system, which could grow into a much larger implementation, as the 
customer discovers its power and utility. 
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IV. METHODOLOGY 



A. INTRODUCTION 

A methodology is a “comprehensive, multi-step approach to systems 
development” (p.8, Hoffer, George, Valacich, 1996). The development methodology of 
the ESU Intranet project was the Waterfall Model . Aspects of the Rapid Prototyping 
approach were also used to physically design the product. 

The Waterfall Model, otherwise known as the Systems Development Lifecycle 
(SDLC), is a relatively formal process of clearly defined steps, which occur discretely one 
after another. The Waterfall Model is typically used to develop large-scale information 
systems. 

Rapid Prototyping sometimes referred to as Rapid Application Design (RAD), is a 
much less formal method of iterative development. RAD is intended to quickly develop a 
prototype that can either become immediately operational or redesigned later using a 
more comprehensive formal approach. 

The first goal of this project was to develop an actual working Intranet product. 
The Waterfall Model was used as the complete lifecycle model for development from 
beginning to end. The Waterfall Model provides a comprehensive framework for 
information systems development from requirements analysis at the outset until a final 
implementation by the close. 

A second goal of the project was to develop a prototype that demonstrates the 
capabilities of the technology. The final product can actually be regarded as one phase of 
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a Rapid Prototype iterative design loop. From this perspective, the Intranet is never 
really completed. Following the initial installation, it is continuously improved and 
refined locally by the client. 

B. WATERFALL MODEL DEFINED 

The Waterfall Model is a multi-stage, comprehensive methodology with seven 
clearly defined steps. The approach uses a formal process to systems design that reduces 
the probability of bugs in the design. With its emphasis on proper requirements analysis 
at the beginning and on proper implementation and maintenance at the end, it widens the 
development perspective to include more than just a focus on writing computer code. 

The seven stages, as described in the textbook Modem Systems Analysis and 
Design (p.24, Hoffer, George, Valacich, 1996), are presented below. 





Li\ Implementati 
’ — ✓ on 



Figure 4.1 Waterfall Model of the Systems Development Lifecycle 
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The Waterfall Model is an excellent choice for a structured development effort 
conducted in discrete phases. The project is scheduled with timelines and critical 
milestones. It is a very good method for developing systems to meet well defined, 
mathematical requirements. The customer tends to prefer this methodology as the 
progress of the development effort is well documented and scheduled in phases. 

There are disadvantages of the model. It is difficult to use when a customer 
cannot clearly and specifically articulate system requirements. Documentation and 
analysis using Data Flow Diagrams (DFD), Entity-Relationship Diagrams and other 
Computer Aided System Engineering (CASE) tools can lead to a never ending cycle of 
analysis, or “analysis paralysis”. There is very little room for risk analysis as the project 
progresses on its schedule. 

Although not all aspects of the Waterfall Model were entirely appropriate for the 
ESU Intranet development, it did provide a structured methodology to follow. The 
chapters of this thesis, and the development aspects they cover, are related to each phase 
of development under the Waterfall Model. The seven development stages of the 
Waterfall Model, with the thesis chapters that correspond to a particular development 
stage, are presented in Figure 4.2. 
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Waterfall Model Stages - 


; ' Thesis Chapters 


1. Project Identification and Selection 


Chapters II, III, IV 


2. Project Planning 


Chapters II, III, IV 


3. Analysis 


Chapter V 


4. Logical Design 


Chapter V 


5. Physical Design 


Chapters VI, VII, VIII 


6. Implementation 


Chapter IX 


7. Maintenance 


Chapter IX 



Figure 4.2 Stages of Waterfall Model and Thesis Chapters 



C. WATERFALL MODEL APPLIED 



1. Project Identiflcation and Selection 

The first phase of the waterfall is project identification and selection. During this 
phase, a range of projects and ideas is considered and a general conceptual project idea is 
selected (p.24, Hoffer, George, Valacich, 1996). Selection is based on various factors 
such as feasibility, cost versus benefit, the readiness of the organization and the 
capabilities of the development team. 

For this thesis, several potential USCG test environments were considered. These 
included an Intranet for a USCG cutter, for a small boat station, or for an office 
environment. Electronic Support Alameda was the final choice. 

ESU Alameda was selected as the thesis sponsor primarily because it is an 
innovative Command which is on the cutting edge of the Coast Guard information 
technology changes. The ESU’s Commanding Officer officially states in ESU Alameda 
Standard Operating Procedures Instruction 5400. IB that he expects each employee “to 
improve our system of doing business, to be innovative” (p.l. Lane, 1996). 
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ESU Alameda was especially receptive to the idea of sponsoring a prototype 
Intranet development effort. Unlike most Coast Guard units who have older, non- 
Windows based computers, ESU Alameda already had the hardware and software 
requirements necessary for a Microsoft Windows based Intranet. Specifically, they had 
networked IBM-compatible computers running Microsoft Windows NT Server and 
Workstation operating systems. 

2. Project Initiation and Planning 

During the project initiation and planning phase, the general information systems 
concept begins to take shape. The project is initiated when the customer is contacted. 
The feasibility of the project, the costs and benefits of it, the scope, and objective are all 
considered. For large scale systems development using the Waterfall Model, a formal 
report would generally be written after this stage which would cover all of these issues at 
length, (p.25, Hoffer, George, Valacich, 1996). 

For this project, the process was much less formal. ESU Alameda was contacted 
and the Intranet idea proposed. The ESU Command welcomed the development effort 
and pledged its support. A cursory analysis of the current state of the ESU’s information 
systems was done via telephone and the project was determined to be feasible. The ESU 
made money available for travel to Alameda in order to conduct the business analysis and 
agree on requirements. 
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3. Analysis 



The Analysis phase is one of the most important steps to information systems 
design. It is when the client’s business model is examined in detail. The design team 
must thoroughly miderstand current business processes and select candidate processes for 
Intranet development. The customer’s requirements for a successful system are 
determined. The flow of information, data and business processes are exhaustively 
explored and diagrammed, (p.25, Hoffer, George, Valacich, 1996) 

The business model analysis was conducted over a two day visit to the ESU. 
Interviews were conducted, meetings were facilitated, and documents researched in order 
to reach a clear understanding of the ESU’s mission, their business model, and their way 
of doing business. Requirements analysis revealed the top goals and problems the ESU 
faced. 

Following the business analysis, it was possible to narrow the scope of the project 
to focus on the Command’s top priorities. These three top priorities were found to be: 

• keeping better track of personnel movements and administration 

• improving the supply ordering and procurement process 

• status monitoring of Casualty Report (CASREP) service requests 
The business analysis is thoroughly explored in Chapter V. 

4. Logical Design 

The logical design phase is when the components of the information system are 
defined without regard to any specific hardware or software platform. The functional 
goals of the system are visualized without consideration of the physical implementation. 
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The logical design phase focuses on business processes and conceptual system solutions 
for them. By the end of this phase developers should have a clear idea of what they want 
their system design to do. (p.25, Hoffer, George, Valacich, 1996) 

A functional decomposition diagram (see Figure 5.9), which is the logical 
blueprint for the Intranet, was the main product for this phase of development. The 
diagram included all the system design goals without regard to actual physical design, 
software tools or hardware platform. 

5. Physical Design 

In this phase, the logical design is converted into an actual physical 
implementation. The process of turning the concept into a reality includes deciding what 
software tools to use, what platform to develop on, what language to code with. Chapter 
VI describes in detail why certain software tools were selected for developing the ESU 
Intranet. Chapter VII details the necessary steps to building the product. 

It is impossible to express the tremendous amount of effort it took to learn, plan, 
write and document bug-free code to make the Intranet engine turn. Fortunately, it was 
possible to reduce the complexity by following the logical blueprint of a functionally 
decomposed system. Functionally decomposed means the Intranet was modular and 
broken down into parts. Individual parts and applications could be separately developed 
in discrete modules. 

The interactions between modules of the system are complex enough, however, 
that good documentation of the code was absolutely critical to success. Considerable 
effort went into ensuring that descriptive documentation accompanied all code. 
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6. Implementation 



Implementation includes all aspects of introducing the new information system 
into the organization. This includes installation, testing, and support (p.26, Hoffer, 
George, Valacich, 1996). The implementation phase is more than the technical aspects of 
physical installation and software loading. The social aspects of introducing an 
information systems change into an organization must also be considered. It is the social 
aspect, far more than the technical, which will ultimately determine the outcome of the 
implementation. 

Managerial obstacles to a successful implementation of the Intranet are abundant. 
Any change that redefines the lines of communication in a system is likely to meet with 
resistance from employees who may prefer old, established patterns. These and other 
social change issues are explored in Chapter IX. 

7. Maintenance 

The final phase of the Waterfall Model is maintenance. Most of the lifecycle 
costs associated with a new information system occur during the maintenance phase. 
(p.26, Hoffer, George, Valacich, 1996) In many instances, the system designers are long 
gone when real problems occur. For this reason, it is incumbent upon the developer to 
provide the client with good documentation, training and a method for system change 
requests. 

The ESU Intranet was designed with maintenance in mind. The code is 
painstakingly documented to allow for a higher degree of maintainability. A separate 
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"Help" Web site was included on the Intranet to provide information regarding 
maintenance, support, and systems feedback. 

D. RAPID PROTOTYPE METHOD 

Many customers don’t know what to ask for or how to describe their information 
system needs. Showing them an example, or prototype, is a very effective method for 
allowing customers to clarify their requirements. The prototype can demonstrate 
capabilities of a technology that the customer did not even know existed. It provides a 
good starting point, which may then be adapted to the individual customer needs. The 
final result of this thesis, the ESU Intranet, is essentially a prototype. 

Rapid Prototyping is a series of iterative loops of development, testing, feedback, 
and then development again (p.28, Hoffer, George, Valacich, 1996). Customer 
requirements are initially highly abstract, meaning they are fuzzy and unclear. The 
iterative loops of the Rapid Prototype method clarify the system requirements until, 
eventually, a working model takes shape. The prototype may then be used as a functional 
system or as a model for a larger development effort. 
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Figure 4.3 Iterative Development using the Rapid Prototyping Process 

The Rapid Prototype method has advantages. It is ideal for a small, 
uncomplicated project. Development can begin before final approval of funds becomes 
available. Various modules and portions of the project can be developed vvithout having 
to stick to a schedule or await critical milestones. 

The method also has dangers. Unlike the Waterfall Model, which proceeds 
sequentially through seven well-defined steps including a physical design phase, the 
Rapid Prototype is always in the physical design phase. Since the requirements for the 
system are continually refined or changed throughout the development, the final product 
may turn into a “build and fix” solution. The resulting system code might not flow 
consistently and it is likely that it will be patchy and disorderly. This kind of tangled 
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“spaghetti code” can be difficult to maintain or understand. By contrast, a system 
developed using the Waterfall Model should have reasonably consistent code because all 
the requirements and specifications have been defined and logically modeled prior to 
physical design. The cost of a system developed by the informal Rapid Prototype model 
may be greater than the Waterfall Model in the long run. 

E. CONCLUSION 

This chapter defined two methodologies for systems development that were 
relevant to this thesis. The thesis progressed through each sequential phase of the 
Waterfall Model because it provided a baseline plan for the entire development effort. 
The result of the development under the Waterfall Model was a prototype ESU Intranet. 

The Rapid Prototype model is relevant because the final result of the thesis, an 
ESU Intranet, can be regarded as simply one iteration of the model. The implementation 
process at ESU Alameda will determine if the final outcome falls to the left (first 
prototype), middle (revised prototype), or right (final prototype) in Figure 4.3. In any 
case, the ideal goal of the thesis was to provide the ESU with a “vision of what is 
possible” with Intranet technologies. If the prototype is adopted as a functional, 
operational system that is constantly revised and enhanced, as shown in Figure 4.3, then 
the goal will have been far surpassed. (See Chapter IX for more discussion on 
implementation issues.) 
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V. ANALYSIS 



A. INTRODUCTION 

The analysis phase focuses on the business model and processes of the client. A 
systems perspective was adopted to analyze the ESU business model. Instead of simply 
focusing on discrete linear processes, the potential benefits and consequences of Intranet 
technologies for the entire organizational system were considered. The idea that one 
should not simply automate existing paper processes was a guiding principle during the 
analysis phase. The goal was to obliterate, or re-define, old processes with the power of 
new Intranet technology. 

This chapter will explore the business analysis and how it was conducted at ESU 
Alameda. The most important findings, specifically the identification of the ESU’s top 
priorities, are presented. These top goals drove the Intranet development and narrowed 
the field of candidate processes to be modeled for Intranet applications. A logical, or 
conceptual, model was derived from the business analysis results. The logical model is 
presented here. 

B. PROCESS ANALYSIS METHOD 

1. Systems Perspective 

The Fifth Discipline , by Peter Senge, advocates a systems approach to thinking 
about organizations, which provided the basis for exploration of the ESU business model. 
Systems thinking involves seeing the organization as whole system of circular 
interdependencies. The opposite of systems thinking would be to view the organization 
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as being broken up into unrelated, independent, linear processes. Systems thinking is 
about “seeing processes of change rather than snapshots” and “seeing interrelationships 
rather than linear cause-effect chains”, (p.73, Senge, 1990) 

Simply automating existing paper trails with new Intranet technology would be 
like taking a “snapshot” of the process. Instead of approaching business processes one at 
a time, the research focused on business areas. The goal was to find ways of altering, 
enhancing or eliminating processes in ways that would benefit the entire organizational 
system, not just a single person. With its ability to improve communications across 
organizational boundaries, an Intranet is an ideal tool to approach fi'om a systems 
thinking perspective. 

2. Method 

The field research consisted of two days of exhaustive interviews, meetings and 
documentation reviews. The original interview plan was to identify business processes, 
and match factors, such as how many people a process affects, against certain criteria. 
Correlation of these factors with these criteria was designed to indicate a process' 
suitability for an Intranet solution. The plan had to be modified mid-way through the site 
visit, as it became apparent that a much different method of analysis illustrated the 
business processes more clearly. 

The research began with interviews of key personnel. Using a pre-planned set of 
questions and forms (see Figure 5.1), these interviews were intended to identify specifics 
of business processes and provide a foundation to rank order the suitability of a process 
for an Intranet solution. 
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ESU Alameda Process Analysis 

Please pick one important process you do in your job (i.e. order parts) and answer these questions. Thank- 
you. 



ESU Alaiiicda Process Aiinlysis IiiteiA.’iew 

I What your RanK R^te and Job Title? | | 



Please pick one impaitantpirocegs you do in. your job (i.e. order pgts) md answer qmstiong. 



What is this process? 




Please Describe it briefly. 





1 . How many people does 
this process affect? 


□ One □ Two □ 3-5 □ 6-10 □ 10+ □ 20 + U Evoyone at VrtjL 
Other 


2. Who are the people or 
thin^ that are affected by 
this process? 




3 . How does this process 
affect them? 




4. Who are the people or 
things that use this 
process? 




5 . How many people are 
involved in doin^ it? 


U Orta CJ Two U 3-5 tJ 6-10 LJ 10+ □ 20 +D Evoyone at tJkuL 
Other 


6. Who is the primary 
owner (doer) of process? 




7 . How often is this process 
used? 


□ □ Weekfy’ D Monthly U Quaotier^ U iVromilly 

Other 


8. How often is this process 
updated? 


□ Daify* □ Weekly □ Monthly □ Qiuiter^ □ 

Other 


9. Please identify some key 
personnel or things and 
how they interact with 
this process? 


PersonTThins 


Person/Thins 


□ L is 0|>daled Once, Used Once 

□ 1. is Ii|>d;aled Once, Used Mery Times 

□ L is X^pdeted Mary Times, Used Once 
O Updated Many Times, Used Many Times 


□ 1. is 0|>dated Once , Used Once 

□ fi. is updated Once , Used Mary Times 

□ L is U|)dated Mary Times, Used Once 

□ Updated Many Times, Used Many Times 


10. What is the type of 
information or data input 
for this process? 


Q General (i.e.. AL CO AST messageO 
O Private or 
□ Classified or 

D Low Volume or, D Medium Volume or 


L2 Customiaed (i.e . wiitingthe Plan, of D^) 

□ Non-private 

□ Unclassified 

□ Volume 


1 1 . What is the current status 
of data storage and 
computer or network 
automation of this 
process? 


□ Manual (i.e. using desk folders, filing cabinets, etc.) 

D Partly Automated (^lan-netwooked standalone computer) 

♦ Using Word Processing files 

♦ Using Database 

D Rilly Autcmated (using non-netwoiked standalone computer) 

O F\iUy Autcmated and Netwod<ed with links to other processes 

♦ Camputers exchange infoimatian., files, data, with other people orprocesses 

□ Alreax^ on the fotranet 


12. Comments or anv other 





Figure 5.1 Original Process Interview Questionnaire 

Using the prepared interview questionnaires was not as successful as anticipated. 
Personnel were unable to clearly articulate, in words, the specific information flows and 
processes of their day to day work. One on one interviews failed to produce useful 
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information until the approach was modified to drawing pictures that modeled an 
employee’s daily processes. 

The most valuable method of understanding the ESU Alameda organization and 
business process flows was to talk through the jobs of key personnel by drawing them on 
whiteboards as Data Flow Diagrams (DFD). The DFDs helped ESU employees articulate 
what information flowed to whom, why, where it was stored and how it was used. The 
parts and supply ordering process, for example, was so complicated that it was almost 
impossible to describe without using a drawing. The process is shown in Figure 5.2 as a 
DFD. 



40 




Figure 5.2 DFD of Supply and Parts Ordering Business Process 
From the visual DFD maps, it was possible to redesign the system by looking at 
how entire processes and information flows could be redirected with the communications 
potential of an Intranet system. New methods of data, information, and workflow were 
conceived. In most cases, the new designs did not simply automate the original DFD, 
rather they obliterated the old DFD. Redesigning processes necessitated a fresh DFD to 
accurately portray new information flows. For example, new DFDs of the Intranet 
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solution to the supply process were developed which significantly reduce the complexity 
found in Figure 5.2. (See Figures 5.5 through 5.7 for the new DFDs.) 

C. ESU ALAMEDA BUSINESS MODEL 

1. Overview 

ESU Alameda is responsible for the maintenance and support of all electronics 
throughout their Coast Guard geographic area of responsibility. They are a mid-sized 
service oriented organization with roughly 50 employees. They are a fairly typical USCG 
unit with most of the same pressures, procedures, and paperwork of any other unit. 

2. ESU Customers 

The ESU has internal and external customers who could benefit from Intranet- 
solutions to day-to-day business needs. 

Internal customers can be grouped in many ways, from command or management 
level to the office worker. Internal customers could be grouped by rank, civilian or 
military. Internal customers have different needs depending on which group they belong 
to. 

Its’ external customers, those whom the ESU provides services for, would be 
interested in ESU products and news relevant to their service requests. Other external 
customers could be anyone who needs to reach the internal employees of the ESU. 
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3. Organization 



ESU Alameda is a typical hierarchical organization organized in a tree structure. 
It has a military chain of command beginning with the Commanding Officer (CO) and 
Executive Officer (XO) at the top. The ESU is then divided into distinct divisions, or 
branches, with a Division Head in charge of each. 



ESU Alameda Organization (Active Duty) 



kctronic 

fins" 

BCN 3396901 



Vessels 




Section 




(ELC4) 




8CN 3399342 







Shore Section 

(ac4) 

B(>JJ399332 

(CT1) 

8CN«)04849 

PipelifleTechJ 



Commanding Officer 
(COR) BCN 1199841 






Executive ' 
(LCDR) BC 


Officer 
N 1199831 



COTR (GS-11) 
PCN 33031 5P 



OAL Section 

m 

BCN 3387703 
BCNU0O3878 
aCN 3387663 

6CNU003877 



Contract Shoj» 

HumboWt Soy 
Alomedo 
Monterey 
Son Pedro 



Informofion Resource 
Monogement Officer 

(LT) BCN 339921 1 



Business Servfcos 

(GS-r,PCN33l022P 
(SK1)8CN 1198313 
(CS-5) TempOftry Employee 



ESU Detochmcnis 
(LT) BCN 1199821 

Southern CA XPO 
(ETCS) BCN 3383883 



Dll Telecomms 
fTTCS) 

BCN 3399193 



CG isicnd 
Telecomms 

(ac4) 

BCN 3399702 



I Nomedo TT Shop 
>C) 

8CN 339S963 

m 

BCN 3396973 
(TT2) 

eCN33$$963 

(IT3) 

KN 3395943 
BCN 3396953 
BCN 3384733 



CG Island PBX 

(CS-9) 

PCN 330073P 



Compwtef 

$up{^ 

(CS-12) 

PCN330062P 

(TCCS) 

BCN 1 104833 
(TC2) 

BCN 1106013 

(CS-7) 

PCN330052P 

(2) Un‘i^ Techs 



Netwo'lts 

(GS-12) 

PCN 331023? 

(TCI) 

BCN 3335613 
8CN 1188073 



RSM's 


Alomedo 


Humboldt Boy 


(nC) BCN 1174393 


mi) 8CN 1188023 


(rc2) BCN 1188013 


Croup SF/YBI 


Socromenlo 


(TCI) BCN 1188003 


<TC2) BCN 1188053 



Son Pedro IRU 

(CS-12) 

PCN331024P 

(GS-11) 

PCN 331025P 

aci) 

BCN 1175863 
BCN 1 188053 

(H2) 

BCN 1188043 
(1) Unisys Tech 



0A£ Son Prd'O 
(ETC) 

BCNU003877 



Son Pedro TT Shop 
(TTl) 

BCN 3383893 
OT3) 

BCN3383SKJ3 



Del Son O'e^o 
(ETC) 

BCN 1105353 

m) 

BCN 1105343 

m 

BCNU004a5C 
BCN 1105333 

(TCI) 

BCN 1 188033 



OetOiftOfd 

(ETC) 

eCN 1103023 

(CI2) 

BCN 110100} 

(Ci) 

son 10101 J 



Figure 5.3 ESU Alameda Organization 
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4. Information Flows 



Approval authority for ESU policy decisions, personnel actions or budget 
allocation follows the traditional military chain of command. Final responsibility for all 
decisions at the Command rests with the CO. 

The CO delegates his authority as appropriate. ESU Alameda considers itself an 
innovative organization. Despite the traditional hierarchical structure, information flows 
are not strictly linear. The CO states clearly in the ESU Standard Operating Procedures 
that he expects employee empowerment and communication across organizational 
boundaries. 

“My intent is ... to encourage action and decision making at all levels... Use the 

organizational chart as a starting point; it's not set in stone... (p.2. Lane, 1996)” 

5. Business Model Analysis 

The business model analysis was approached from a high level of abstraction 
where, first, the fundamental mission of the organization was identified. Following that, 
the long-term goals that support the mission were ascertained. Next, the critical success 
factors necessary to accomplish the long-term goals were found. Finally, the specific 
processes that contributed to each critical success factor were determined. Figure 5.4 
provides a snapshot of this analysis. 
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Missions 

use G ESU 
Alameda is 
responsible 
for. 


Goals 

To accomplish the 
mission, USCG 
Alameda 's goal is 
to... 


Critical Success Factors 
To be succes^land accomplish the goal, USCG 
Alameda must have 


Processes 

To be successful, these processes 
occur 


Providing 
world class, 
top quality 
electronic 
support to 
customer 
units 


Ensure operational 
readiness of all 
mission essential 
equipment onboard 
USCG units m the 
area of 
responsibility 


• Means to determine mventory, parts, and 
supply order status. 

• Means to anticipate persotmel 
admimstrative needs and whereabouts far 
enough m advance to budget these costs 

• Means to determine status and location of 
outstanding Casualty Reports (CASREPS) 

• Means to track results of repairs and 
customer satisfaction 

• Means of commumcatmg with internal and 
external customers 


=> Track supply order chain. 

=> Track and forecast current 
personnel whereabouts and admin 
=> Information flow to ESU to 
maintain database with current 
outstandmg CASREPS and work 
orders 

^ Measure customer satisfaction 
and store data 

=> Measure trouble calls and store 
data 



Figure 5.4 ESU Alameda Business Model Chart 
This systems thinking approach to analysis was intended to eliminate noise by 
identifying the truly important processes, which could be, traced back to supporting the 
ESU’s mission. Business practices that were not aligned with the ESU’s strategic goals, 
or did not add value to the ESU’s critical processes, were not considered candidates for 
Intranet solutions. 



D. CRITERIA FOR SELECTION OF INTRANET SOLUTIONS 



1. Command’s Top Goals 

So many processes were suitable for Intranet solutions that the scope had to be 
narrowed in order to have any reasonable chance of accomplishment. The Command’s 
top goals, or problems to manage, were clearly xmcovered during the research. The top 
three were found to be; 

• keeping track of personnel movements and administration 

• improving the supply ordering and procurement process 

• status monitoring of Casualty Report (CASREP) service requests 
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The development effort concentrated on broadly meeting the top goals of the ESU 
Command rather than focusing on a specific workgroup’s narrowly defined problems. 
The high level focus makes the most sense from a systems perspective because the 
Command’s priority processes are global, meaning their impact stretches throughout the 
entire organization. 

2. Feasibility 

The scope of the Intranet project was limited on a practical basis due to 
constraints such as limited time, technical feasibility, and developer skill. The difficulties 
of turning a logical, or conceptual, design into a reality were significant. These 
constraints are addressed in Chapter III. 

3. Showcase Intranet Potential 

Bearing in mind that one goal of this thesis is to demonstrate the power of an 
Intranet for a Coast Guard unit, it follows that one of the criteria for selection of Intranet 
processes was to showcase the potential and capabilities of the technology. Applications 
that could change the organization, obliterate inefficient processes, or distribute 
information horizontally across departments, were conceived. The CO’s principle, as 
stated in the SOP, to “allow maximum flexibility ... for action and decision making at all 
levels” was guiding, (p.l. Lane, 1996) ' 
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E. 



LOGICAL DESIGN 



1. Requirements Analysis 

Informal requirements analysis was used because the goal of the project was to 
demonstrate the capabilities of a new technology and the requirements were unclear. The 
business model was examined, as described above, and an informal conceptual idea of the 
desired functionality was attained. Informal requirements analysis was a continual 
process of refinement because, basically, people did not know what an Intranet is so they 
could not articulate firm requirements for one. This is why one simple goal of the project 
is to build a prototype and demonstrate what is possible. 

2. Data Flow Diagrams 

Data Flow Diagrams, resulting from research into the ESU business model 
revealed the critical elements of ESU business practices. It was then possible to imagine 
new methods of doing business, and new DFDs, that take advantage of Intranet 
technologies. These new logical designs change many elements of the process including 
the forms used, the persons involved, and the roles played by each. 

The chaotic complexity of the parts ordering system, as seen earlier in Figure 5.2, 
is significantly changed when remodeled with Intranet technologies. The new DFD 
redefines the roles of the storekeeper and the person who places an order. In the new 
DFD, the person placing the order has more information immediately available to them, 
but they also must take more responsibility for personally tracking the order’s status. 
This alleviates time the storekeeper previously spent tracking orders. 
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Figure 5.5 Level O DFD for Entering Intranet 



In the Context Level DFD shown in Figure 5.7, either an internal or external user 



enters the ESU Intranet. 




Figure 5.6 Level 1 DFD for Intranet 



In the Level 1 DFD, the Intranet user can select to enter the Supply application. 
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Figure 5.7 Level 2 DFD of Supply Application 

The Level 2 DFD shows the logical information flow for a Supply database 
application. This new model greatly reduces the complexity of the original supply and 
parts ordering processes shown earlier in Figure 5.2. 

New DFDs that incorporate Intranet solutions were developed for other processes 
uncovered during analysis. They included DFDs for personnel administration, leave 
tracking and distributing communications. 

The decomposition of the processes beginning from a high level of abstraction 
and working down into the details of the process clearly illustrates the systems focus of 
the Intranet logical design. DFDs were crucial to understanding the information flows of 
the system. They provided excellent conceptual blueprints of the system processes and 
interrelationships, as well as good starting points for actual physical design. 
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3. Desired Functionality 



The desired functionality of a prototype Intranet was determined by the criteria 
indicated above; the command’s top goals, feasibility, and a showcase for the potential of 
Intranet technology. Using those guidelines, the developer settled on several functional 
application concepts for the Intranet. They are listed here in a table with the desired 
logical application and the selection criteria. 



Application 


Does it 
Addresses 
Command’s Top 
Goals? 


Is it Technically 
Feasible? 


Does it Showcase 

Intranet 

Technology? 


Leave Request 


yes 


yes 


yes 


Phonebook 


yes 


yes 


yes 


Customer Service Hotline 


yes 


yes 


yes 


Supply Tracking 


yes 


somewhat 


yes 


Temporary Assigned Duty 


yes 


yes 


yes 


Personnel Reports 


yes 


yes 


yes 


File Uploads/Downloads 


yes 


yes 


yes 


On-line Discussion Forum 


yes 


yes 


yes 


CASREP Tracking 


yes 


yes . 


yes 



Figure 5. 8 Logical Applications with Criteria for Selection 



4. Functional Partitioning 

Functional partitioning is a process of describing what a system is intended to 
accomplish, and then breaking the system into the components that will do it. The 
desired functionality of the Intranet is shown in Figure 5.9 as a functionally decomposed 
logical design. This method of logically viewing a system is neat and modular which 
provides a good starting point for the actual physical design. All of the components that 
were anticipated for development, starting with the top “system level”, and layering 
down, are shown. 
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Figure 5.9 Functional Decomposition Diagram of ESU Intranet 
This functional decomposition diagram was a major product of the logical design 
phase of ESU Intranet development. The digram includes all the system design goals 
without regard to actual physical design, software or hardware platform. 

F. CONCLUSION 

This chapter described the process of research and analysis of the ESU Alameda 
business model. The criteria for selection of Intranet processes were introduced and the 
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logical design of an Intranet system was presented. The end of the Analysis Phase 
marked the demarcation point between concept and reality. The first five phases of the 
Waterfall Model resulted in a logical picture of the desired system. What remained ahead 
was the hard work of building the system to the blueprint. 
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VI. SOFTWARE TOOLS 



A. INTRODUCTION 

Specific software tools are required to create an Intranet. All Intranet users 
require a Web browser to view Web pages on the site. The developer must have a tool to 
design individual Web pages as well as to visually develop an organized Intranet site 
layout and navigation scheme. A database program is necessary to store, query and add 
Intranet data to. The middleware component facilitates interaction between a Web 
browser and a database. Finally, an Internet Web Server is required to host the Intranet 
site. 

B. SOFTWARE TOOLS 

1. General Selection 

The criteria for selecting software tools included assessing cost, availability, ease 
of use, functionality and compatibility with current Coast Guard platforms. A complete 
Microsoft solution was chosen primarily because their software tools met all of those 
criteria. Microsoft’s tools were easy to learn, they were available at no cost, and each 
product seamlessly integrated with another. As well, Microsoft Windows NT and 
Microsoft Office Suite are the official standard Coast Guard operating system and office 
tools, respectively. 
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The software tools necessary and the ones chosen are listed below: 



Software Tool: 



1. WebBroy/ser ' '-'i 

2. Web Page & Site Authoring il 

3. ;- Data.base;yy« - 

4.. Datkb^eMid^ 

5. Web Server _ ' 

6. Operating System . a 

7T Miscelianeo^ Components 





Version Used: 



Microsoft Internet Explorer 4.0 
Microsoft Front Page 98 
Microsoft Access 97 (ODBC Compliant) 
Microsoft Active Server Pages 1 .0 
Microsoft Internet Information Server 3.0 
Microsoft Windows NT 4.0 
Microsoft ODBC 
ASPMail 2.5 



Figure 6.1 Software Tools Chosen for Intranet Development 



2. Web Browser 

An Intranet is viewed through any standard Web browser. Web browsers translate 
the coded text files, mostly written in Hypertext Markup Language (HTML), into graphic 
pages displayed in the browser’s window. One of the most powerful features of a Web 
browser is that it provides a standard application interface for any Internet or Intranet 
content, regardless of the hardware platform the Web browser is running on. 

Internet Explorer 4.0 (IE4) was chosen for its easy integration with other 
Microsoft Office applications, its stability, its support for Web scripting languages, and 
its optimal suitability for interfacing the Microsoft Active Server Pages middleware 
component. 

The other alternative was to adopt Netscape Communicator. There are, in fact, 
only very minor differences, such as slight color variations and small differences in where 
graphics are displayed, in the way Web pages appear in the different browser windows. 
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One of the most significant features of the Intranet is that it is platform and Web 
browser independent. It can be viewed on any standard Web browser. The Intranet is 
only optimized for IE4 in the sense that the day to day testing and development effort was 
done using IE4. 

3. Web Page Authoring and Web Site Management 

Web pages are the essential components of the Intranet site. The Web page 
authoring tool is the most frequently used software tool for the site’s development and 
management. 

Requirements for selection of this tool included ease of use, reliability, 
standardization and site management capabilities. Front Page 98 (FP98) was chosen as 
the Web site and Web page authoring tool because of its strong support for total site 
management. It seamlessly integrates with the other Microsoft products such as 
Windows NT, Windows 95, Internet Explorer 4.0, and Active Server Pages. The visual 
development environment of FP98 was easy to use and leam. The development interface 
also allows for immediate access to the raw, underlying HTML code. Access to HTML 
code is necessary because some elements of Web page design cannot be accomplished 
through a visual interface alone. 

An alternative to FP98 is Net Object’s Fusion site tool. Fusion has a very 
intuitive visual interface for Web page and site design. Fusion was not chosen because, 
before publishing to the Web server, it pre-stages the visual layout of a Web page and site 
in a proprietary file format called NOF. It isn’t possible to edit underlying HTML code 
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when the files are stored as NOF files. Since it is sometimes important to access HTML 
code while programming, Net Objects Fusion was not a good solution. 

4. Databases 

Database development was with Microsoft Access 97. Familiarity with the 
product, the fact that it is in everyday use at the sponsoring command, and the fact that it 
is a Microsoft product were the leading criteria for its selection as the Intranet database 
tool. Access 97 is designed for a small office environment but can easily scaled up to a 
more powerful tool like Microsoft SQL Server. 

Access 97 is Open Database Connectivity (ODBC) compliant. ODBC is a 
standardized interface, which allows applications to have access to the data inside a 
variety of different databases, regardless of their unique formats. ODBC provides a 
middle layer that hides the differences between database formats (Fleet, Warren, Chen, 
Stojanovic, 78). 

Any ODBC compliant database, such as those offered by IBM, Oracle or 
Informix, could be used on the Intranet. These options are designed for enterprise wide 
applications and were considered beyond the scale of this small project. 

5. Middleware 

Middleware provides the language for communication between a database on a 
server and the pages generated dynamically and output to a client’s Web browser. 
Deciding on a powerful, yet easy to use, middleware solution is a crucial decision for the 
Intranet developer. This project uses Microsoft’s Active Server Pages. 
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The field of alternatives is wide. There were many alternatives for large database, 
enterprise wide solutions from Oracle and Informix. These solutions were more 
appropriate for large mainframe based operations. For the mid-sized organization, 
middleware products such as IBM’s Domino and Microsoft’s SQL server compete. The 
alternatives for a small office setting included Allaire’s Cold Fusion and Microsoft’s 
Active Server Pages (ASP). Both Cold Fusion and ASP can be scaled to larger settings, 
all the way up to enterprise. The enterprise products, however, were considered too 
powerful for this thesis. 

Cold Fusion is arguably the most established middleware product available today. 
Allaire’s most recent version even includes a visual development tool for Web enabling 
databases. Cold Fusion has been on the market for several years and is currently in use 
by such companies as Federal Express, Dell Computer and Ticketmaster (Forta, 1997). 

Microsoft’s Active Server Pages middleware product is relatively new. The term 
Active Server Pages is less than two years old. Microsoft currently has no visual tool 
available for writing ASP code and everything must be handwritten using a text editor. 

Both ASP and Cold Fusion are middleware products that run on a host server and 
are very similar in their implementation and execution. The code is executed on the Web 
server, which will then query a database, and finally dynamically generate a Web page 
based on that query. 

The primary criteria which led to the selection of one product, Microsoft’s Active 
Server Pages, over another, Allaire’s Cold Fusion, was cost. Microsoft’s product is free 
and will run on any Windows NT server where ASP is installed. Cold Fusion costs close 
to one thousand dollars per license. 
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Other criteria included Microsoft’s implementation of Visual Basic Script 
(VBSript) as the language to manage the interactions between the Web server and client. 
VBSript is an extension of the Visual Basic language, which is widely supported. New 
components that work with ASP are constantly being developed and sold by third-party 
vendors other than Microsoft. Cold Fusion, in contrast, uses a proprietary scripting 
language and specialized “tags” throughout for its code. 

6. Internet Web Server 

The Internet Web Server hosts the site. Microsoft’s Internet Information Server 

3.0 (IIS) was the natural choice because it is free as an integral part of the Windows NT 

4.0 operating system. Windows NT 4.0 is the Coast Guard’s official standard operating 
system. ASP was also designed to run on IIS. 

C. CONCLUSION 

The software choices made here determined the shape of the resulting Intranet 
product. These tools have both their strengths and limitations when compared with other 
tools. Nevertheless, they all met the most important criteria for selection, which was 
cost, ease of use, functionality, and quality. 
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VII. PHYSICAL DESIGN 



A. INTRODUCTION 

Physical design is the fifth phase of the Waterfall Model. The physical design 
phase took four months of development effort during which, the prototype Intranet was 
physically built. Intranet applications took shape through an iterative, Rapid Prototype 
process of design and redesign. 

This chapter briefly describes the technical aspects of physically building an 
Intranet. A tutorial on how to connect to a database through a Web browser, using Active 
Server Pages, is presented here. Finally, graphic user interface design principles and 
security aspects of the Intranet are discussed in this chapter. 

B. PHYSICAL DESIGN STEPS 

Turning an Intranet concept into a reality requires following certain general steps. 
This following section describes, as a short tutorial, the basic design steps for a Windows 
NT based Intranet using Active Server Pages. 

1. Web Server 

A Web server must be installed on the machine that will host the Intranet site. 

2. Web Authoring Tools 

Web authoring tools used to build the site must be installed on the Intranet design 
machine. The machine must be on the network in order to publish to the Web server. 
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3. Middleware 



The middleware component that will allow an ODBC compliant database to 
communicate with a Web server must be installed. 

4. Database 

A database to hold Intranet data must be developed. Care should be taken to note 
the design details, such as table and field names, as familiarity with the data structures is 
crucial to allow the Intranet to interact with them. 

5. Data Source Name (DSN) 

Using the ODBC control panel from the Windows Operating System, Data Source 
Names (DSN) for the databases must be created. These names will be used in the 
middleware code to reference the Intranet databases. 

6. Intranet 

The physical design should follow the logical blueprint. Authoring Web pages 
and building a site layout creates the Intranet. Some of the Web pages may use scripting 
code and to communicate with a database (through middleware) for information retrieval, 
queries and updates. 
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c. 



CONNECTING TO A DATABASE WITH ASP 



1. Introduction 

This section is a brief introduction of how to connect to a database through the 
Web browser using Active Server Pages. The example only provides a very basic 
overview of the most general method used to do this on the ESU Alameda Intranet. 

The examples found here show the ASP code as it is written into the Web page. 
The code for ASP pages are found only on the server because the server uses the 
underlying ASP code to dynamically generate HTML code when a page is requested. 
The client browser that initiates a request to the Web server never sees the ASP code. 



2. Database 



An Access database used on the ESU Intranet is called “phonebook.mdb”. The 
database has several tables. This tutorial will focus on one table called PERSON, which 
contains fields for employee data. 





PERSON : Table 1 




Field Name 


1 Data Type 


n ^ 


Description 




Rank 


Text 


Enter the rank of the CG person 






Rate 


Text 


Enter the rate of the CG person 






FirstName 


Text 


Enter the first Name of the person 






Middlelnit 


Text 


Entsrjhe m^^ 






LastName 


Text 


Enter the Last name of the person 






Street 


Text 


Enter the street address of the person 






City 


Text 


Enter the city the person lives in 






Stats 


Text 


Enter the state the person lives in 




X 


Zip 


Text 


Enter the zip code at the person's living quarters 



Figure 7.1 Person Table of Phonebook Database 
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3. ODBC and the Data Source Name 



This database has been configured as an ODBC compliant DSN with the name 
“Phonebook”. The DSN name is important to remember because it is used to reference 
the database in the ASP code. 



User DSN System DSN j Re DSN | ODBC Drivers | Tracing | About j 



ODBC Microsoft Access 97 Setup 



Data Source liame: p 

description: 

^ Database 



honebook 



ESU Personnel Database 



T Database; c:\onlinedatabases\phonebookmdb 
i Select.. [ greate... [ Bepa»r... [ 



Compact.. 



I 



OK 



Cancel 



Help 



Advanced... 



Figure 7.2 ODBC System DSN Setup Window 



4. Connection Object 

ASP code is written in Visual Basic script. In this example, a connection object is 
instantiated and named Conn. The connection is made to the ODBC DSN “phonebook”. 
Objects can have properties about them and methods that act on them. In this case, the 
open method is used on the coimection object. 

<%' // Set up connection and open it 

Set Conn = Server.CreateObject("ADODB. Connection") 

Conn. Open "Phonebook" %> 
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5. Recordset Object 



The recordset object iS used primarily to store the results of a database query. It 
may be thought of as a virtual table in memory, made up of rows and columns. In this 
example a recordset object is instantiated and given the name rs. 

<% ' // Set up recordset 

Set RS = Server.CreateObject("ADODB.RecordSet") %> 

6. Define SQL 

The Structured Query Language, SQL, for the desired database query is assigned 
to a variable named SQL in this example. 

<%' // Define SQL 

SQL = "SELECT FirstName, LastName FROM Person"%> 

7. Execute the Query 

Using the recordset open method, the SQL query can be executed. 

<%' // Run Query 

RS.Open SQL, Conn %> 

8. Display the Results 

Finally, the results of the SQL query, which are stored in the recordset object "rs", 
can be displayed. The response, write command (composed of a response object and its 
write method) is used to display the contents of the recordset. A Visual Basic loop, the 
MoveNext method, and the End of File property are used to loop through the recordset 
imtil all records are displayed. 
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<% ' // Write each row 



DO WHILE NOT RS.EOF 

response. write RS("LastName") & ", " 
response. write RS("FirstName") & "<BR> " 

RS.MoveNext 

LOOP 

RS.close%> 

D. GRAPHIC USER INTERFACE DESIGN PRINCIPLES 

1. Introduction 

Simplicity, consistency, elegance, content and usability were the underlying 
Graphic User Interface (GUI) design principles. The following brief list highlights some 
of these principles: 

• Minimal use of distracting colors, flashy logos, or pictures. 

• Focus on consistency across all pages. A common background and header is 
used on all Web pages. 

• Cautious use of frames. Frames are used to divide the Web browser 
window. Frames are tricky to program and can be distracting and annoying if 
they are used improperly. The ESU Intranet only makes use of frames once, 
for the left side navigation bar. 

• Content is king. Every page on the site must have some function, purpose, 
or utility to be included on the site. 
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The design principles are discussed in greater detail in the paragraphs below. Screen 
shots of the Intranet’s pages are presented in Chapter VIII. 

2. Consistency 

Consistency was key in designing the site. Every page has a consistent visual 
background, color scheme and titles. Tasks performed within specific applications are 
performed in a similar manner across all application areas. For example, submitting an 
on-line Leave Request in the Leave Application is almost identical to submitting an on- 
line Temporarily Assigned Duty (TAD) Notification in the TAD Application. 

3. Current Content 

Currency and relevancy was another important GUI design principal. The most 
dynamic data, which changes with the greatest frequency, is immediately presented up 
front on all page layouts. For example, the Intranet Home Page presents the visitor with 
the most current data from four application areas. At a glance, the visitor can see who is 
currently on leave, who is currently away on TAD, what general announcements have 
been broadcast for the command and what user access level they are logged in at. The 
user may follow hyperlinks to drill down into more details of this data. They may also 
scroll down the Home Page for other information that changes less frequently. All pages 
across the Intranet are designed with the principle of putting the most current and relevant 
data at the top of the page. A link is included to further drill down into details about the 
data. 
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4 . Usability 



Usability was another GUI design principle. The applications were designed to be 
used intuitively with little or no user training and with minimal danger of user errors. All 
interactions with the back-end databases are through a common Web browser interface. 
Anyone who is familiar with using a standard Web browser to navigate the Internet 
should have no difficulty understanding how to use these Intranet applications. A user 
only needs to know how to follow hyperlinks and to submit on-line forms. 

The only foreseeable areas where users can make mistakes is in either the 
submission of on-line forms or in the unintended modification or deletion of on-line 
records. In submitting on-line forms users may enter invalid datatypes in certain fields 
which could cause the back end database to reject the entire form. Care has been taken in 
the design process to validate data before it is submitted to the database to minimize this 
risk. There are cases however where data validation is not easily implemented, such as 
validating date formats. In these instances, the possibility exists that the user may enter 
invalid data or an unrecognized format, which will cause an error. In all cases, the user 
has to redo their form or delete the erroneous data. 

5. Deletions 

All deletions across the Intranet are handled in the same manner. Deleting records 
is not a simple one-click process. The user is clearly informed of what they are about to 
delete and given the opportunity to back out. When a delete request is made, a warning 
alert box pops up in the browser window which informs the user that deleting records is a 
serious matter and should only be performed by personnel authorized to do so. The user 
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must click “OK” to continue. Next the user is presented with all the information that will 
be deleted. There is a warning banner in red across the top of the page. A cancel button 
is prominently displayed in case the user made a mistake. Finally, to perform the delete 
the user must press a very large red button that clearly indicates they are about to delete a 
record. 

Deleting records requires deliberate, informed action on the part of the user. The 
site was designed so that there is very little possibility that the user will mistakenly delete 
data. The possibility exists, however that an imauthorized person will delete records that 
do not belong to them. Backups are recommended in case this happens. Command 
policy on acceptable use should specifically address this issue of unauthorized deletion 
and modification of data. 

6. Site Navigation and Menu Bars 

A left-hand vertical navigation bar is implemented as a frame and is always 
present in the Web browser window. The menu bar contains links to general application 
areas. The bottom of each page contains a horizontal menu bar with links to the specifics 
in each of the application areas. The menu also has a link to a site map, which displays 
all links available to Intranet users. 

The left-hand navigation menu is implemented in JavaScript. This enhances the 
GUI human computer interaction because the links change color when the mouse pointer 
is passed over them. 
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E. 



SECURITY FEATURES 



1. How to Use the Security Features 

The command will need to decide on at least four username and password 
combinations to cover the four security access privilege levels. These levels are “sec 
admin”, “admin”, “user” and “guest”. 

A visitor to the Intranet may choose to log in at one of the security levels 
(assuming they have the appropriate username and password) or they may browse the 
“Public Access” areas of the site that are available to the “guest” access privilege level. 

Once a user has successfully logged in, a variable containing the security access 
privilege level value is set and maintained for the duration of their visit. The variable is 
temporarily stored as a cookie in the Web browser using the Active Server Pages session 
object. The session object stores the security access level for the duration of a visit. It 
expires when the visitor exits the Web browser or after twenty minutes of inactivity. 

• Guest access is the default access level for anyone who has not logged in and 
is browsing the “Extranet -public access” areas of the Intranet. This level is 
intended for outside visitors and anyone who is not a part of the ESU unit.. 

• User access is the default access level for anyone who is a member of the ESU 
unit. This level allows access to most areas under the “Intranet - members 
only” banner of the menu bar. It requires logging in with a valid username 
and password. All members of the unit should be given the username and 
password for this access level. Logged in users can view most information that 
is specific to the ESU such as personnel information and recall logs. Users 
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may also add, edit and delete most records contained in the back-end 
databases. Submitting on-line forms such as leave requests, temporary duty 
notifications, and the posting of general announcements can be done once 
logged in under the user access level. 

• Admin access is designed as the default access for supervisory level positions 
at the ESU. This level is used to restrict access to pages that require on-line 
approvals of forms submitted on-line. Admin access allows everything that 
can be done under user as well as access to all remaining areas of the site. It 
is recommended that a limited number of personnel hold this access level as 
one can do almost everything on the site already tmder the user level. Admin 
access should only be granted those persons who hold supervisory positions 
such as department heads, the executive officer and the commanding officer. 

• Sec Admin access is the highest privilege level. This level is designed as the 
top level primarily for administering the databases and deleting sensitive 
records. Only one or two people should have sec admin access. Presently, 
only one application, deleting a personnel record, requires this access level. 
Because deleting a personnel record causes a cascade delete, where the 
primary record and all related records are deleted, one should be cautious in 
who has access to the delete feature. 

2. Security Policy Considerations 

The command is encouraged to test the security implementation as presented and 
modify it as necessary. As a matter of policy, the command may want to further restrict. 
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or allow greater access to certain information contained on the site. The command may 
want to implement individual usernames rather than the four generic usernames. 

• Usernames: 

The default Intranet username which allows user access should be distributed 
freely to all members of the ESU. A specific warning should prohibit ESU 
members from disclosing the username and password to anyone who is not a 
part of the unit. It is recommended that all users sign a form to attest to their 
compliance. 

• On-line “Digital Signatures”: 

Many on-line forms are simply automated versions of an equivalent paper 
form. These forms have the same approval chain as the paper forms which 
were previously routed through the various inboxes and outboxes of the ESU. 
Instead of a pen and paper signature, these forms rely on a “digital signature”. 
The digital signature generally consists of no more than a check in a box and 
the pressing of a submit button in the Web browser. 

Access to these pages where approvals occurs is limited to users logged in 
with security access level of admin. It is recommended that ESU command 
policy for acceptable use of the Intranet specifically address the following: 
that only authorized personnel may digitally sign (hit the submit button) on- 
line forms and requests. It should be pointed out that an unauthorized digital 
signature on-line is the same as forging a signature on the equivalent paper 
form. Presently, even if the digital signature policy was abused, it would not 
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cause mission critical harm (i.e. no money would be misappropriated or 
personnel records lost). At the worst, a member might forge his or her own 
signature for a leave request. Nevertheless, the viability of this security model 
for “digital signatures” should be tested and policy adjusted accordingly. 

3. How Security Works 

Usernames and passwords are stored in the “phonebook” database under a table 
named “users”. Security is implemented on a page by page basis. Every request for a 
page that is protected will first be redirected to a security access level check. One simple 
line in the HTML code, called a “server side include”, will redirect the request to a file 
which is executed before the HTML page is loaded. The include file contains code which 
checks the a session object variable. This variable stores the security access privilege 
level variable assigned to users based on their login. Presently there are three server side 
include files implemented for user, admin, or sec admin access respectively. 

1 . <!--#include file="../user_access.inc"--> 

2. <!— #include file="../admin_access.inc”— > 

3. <!— #include file=”../secadmin_access.inc"--> 

Only one of each type needs to be included before the HTML header for pages that are to 
be protected. 

The following code is an example of using the server side include file to restrict 
access to a page. First the page is commented with an Active Server Pages header, next 
the server side include file is in bold, and finally the beginning of a typical HTML page is 
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shown. If the user successfully negotiates the “admin_access.inc” file then the rest of the 
HTML page is loaded. Otherwise the user is redirected to a “No Access Allowed” page. 
<% 

' * For every page that you want to enable access control, put the include 
' * file and this file in the same directory. 

' * Type <!— #include file="../LoginCheck.inc" — > 

' * BEFORE the <html> tag (very important) at the top of the page you 
' * want to control access to. %> 

<!“#include file="../admin_access.inc"--> 

<html> 

<head> 

<title>Pending Leave Requests</title> 

The source code for the page by page security solution was taken from Jon Mnemonic’s 
article “Access Control With a Database” published on-line at "The ASP Hole". 

F. CONCLUSION 

This chapter discussed the technical details of the physical design phase. The 
actual development effort took months of ASP and HTML code programming. 
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VIII. APPLICATIONS 



A. INTRODUCTION 

This chapter shows the results of the physical design phase, which are the Intranet 
and its applications. The Intranet is composed of over 80 custom built Web pages. 
Screen shots of important pages, with brief descriptions of how the applications should be 
used, are presented here. The goal is to present the reader with an idea of the basic feel 
and functionality of the Intranet application areas. 

B. APPLICATION NAVIGATION STRUCTURE 

The navigation menu of the Intranet is arranged functionally by application area. 
Figure 8.1 shows each the significant pages of Intranet and how they are navigated. 
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Figure 8.1 Intranet Navigation Structure 
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C. HOME PAGE 

The ESU Alameda Intranet Home Page is the starting point for the Intranet. From 
the home page the user may login, view the most current and immediate content, or jump 
off to any of the various Intranet applications. 



0 Welcome to ESU Alameda Intranet - Microsoft Internet Explorer 



j 5 le Edit View fio Fgvontes He‘P 



o L ->> 

Back i Fcward 



© 

Stop 



a 

Refresh 



Home 



a Sa 0 ^ \ B 

Search Favontes Histoy Channels j Fullscreen 



Mail 



Uis 



Print 



I Ad|Backto /-|tp .//127 0 0 1 /prototype 2 / 



Home Pa»e 



Sit« li^ai 



Members OrJ'/ 



1, D;il'jba»es; 

?txsonrit\ 

Srippl-^r 



5. Deputm^AO: 
ConmiAnd Info 



Electronic Support Unit Alameda Intranet 



Welcome admin . You are logged in with security level admin 
General Announcements Personnel on Leave Today 



.Announrempnt 



Posted by iName 



Leave Period ends on! 



Picnic Todayl 1400 detads 



Benhart, Doolittle, Doctor (L*0 5/1 5/98 after 1 5 days 

Palph ^L*I^ , 



5/4/98 




Post a New Announcement 



Leave Summary 

Personnel TAD Today 



Allows for eccess to mfeadtd 

for ESU Bwnbeis oaty. You MUST 
bgiri to have access to databases. 


Username’ 


{user 


Password; j 


i :i 


Login 





Name 


TAD 


Wliexr 




until 





Byrd, Scott CTC2) 
Fife, Barney (LI) 



5/1 0/98 USCGC RELIABLE 
5/10/98 USCGC Bittersweet 

TAD Summary 




OERs/Marks Due in the next 31 Days 
Whose Marks are 
Due 



[who 


jWhen 


j06 


15/10/98 


|E7 


16/1/98 


|CW02j6/l/98 



Click here to see the 
names and status of people 
whose marks are due. 



Plan of the Week 

Click Here! 
Today is 5/4/98 



Figure 8.2 ESU Alameda Intranet Home Page 
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D. PERSONNEL APPLICATION 

1. Introduction 

The purpose of the Personnel Application is to track, forecast, and manage 
information about ESU Alameda personnel. The application interacts with the 
"phonebook" database. Access to this application is restricted to users who have logged 
in at the security session level "user". Access to the application includes the ability to 
view records, add new records and update existing records. Only users logged in at the 
highest security session level of "sec admin" may delete records. 




2. Web Pages of the Personnel Application 

a. List of Web Page Figures: The following table lists the names of the Web 
pages of this application and the corresponding figure numbers. 



Web Page 


Figure 


Welcome Page 


8.5 


Lookup Personnel Details 


8.6 


Edit or Update Personnel 


8.7 


Add New Personnel On-line Form 


8.8 


Delete Personnel Record 


8.9 



Figure 8.4 Table of Web Pages and Corresponding Figures 
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Electronic Support Unit Alameda Intranet 



Personnel Administration Web Database Application 



Select a name from the pull down menu and click 'Lookup' 
then be able to view, edit on^date the data. 



You’ll! |Baker, Jefif(ETl) 

Lookup 




Can’t find yoor record? Click Here to Add new personnel to the database 



Complete ESU Personnel Roster 



iName 


E-Mail 


Depamneiit 




Baker, Jeff (ETl) 


thehannahs (3toecn d net 


ESU Business Services Branch 


details edit delete 


Bartlett, Rex (ETC) 


thehannahs®theerid net 


COTR Branch 


details edit delete 


Benhart, Ralph (LT) 


thehannahs (Stheeri d. net 


Detachment Oxnard 


details edit delete 


Bennett, Darrin (SKC) 


thehannahs(©theerid net 


Business Services Branch 


details edit delete 


Brewster, Punkies (AM2) 


thehannahs Olthecnd. net 


Detachment San Pedro 


details edit delete 


Byrd, Scott CTC2) 


thehannahs (©theeri d. net 


IRM Branch 


details edit delete 


Cantu, Edward (TT3) 


thehann 2 hsO 1 thesrid.net 


IRM Branch 


details edit delete 


Clarice, Brian CTCCS) 


thehannahs Oltheerid, net 


IRM Branch 


details edit delete 


DARDIS,DEANCLT) 


thehannahs04heend.net 


Electronic Systems Branch 


details edit delete 


Doolittle, Doctor (L*D 


thehannahs O^e eri d n et 


ESU Business Services 


details edit delete 


Enberg, Melvin CTCl) 


thehannahs Oltheeridnet 


IRM Branch 


details edit delete 


Farms, Toad (LTJG) 


meOlesu. alameda. cc 


Detachment San Pedro 


details edit delete 


Farms, 653456 (LTJG) 


me Olesu alameda ce 


Detachment San Pedro 


details edit delete 


Farms, dfgh (LTJG) 


meOlesu alameda cc 


Detachment San Pedro 


details edit delete 


Fife, Barney (LJ) 


thehannahs04hecrid.net 


Detachment San Pedro 


details edit delete 


Fontaine, Trevor CTT3) 


thehannahs04hecrid.net 


IRM Branch 


details edit delete 


Gainer, Joanne (GSl 2) 


thehannahs04hecri d.net 


IRM Branch 


details edit delete 


Gardner, Bob (ETC) 


thehannahs04hecrid.net 


Contracted Source 


details edit delete 


George, Joe (ENS) 


thehannahs04hecnd net 


COTR Branch 


details edit delete 


Guiterez, Laura (ETC) 


thehannahs04hecrid.net 


COTR Branch 


details edit delete 


Gunther, Bobcat (LCDR) 


thehannahs04hecnd.net 


Detachment Oxnard 


details edit delete 


Hamlin, Chuck (ETC) 


thehannahsOlhecrid.net 


SoCal Detachment Organization 


details edit delete 



Figure 8.5 Personnel Administration Welcome Page 
b. Welcome Page: The Welcome Page presents the user with a list of all ESU 
Alameda personnel. Links are available for sending email, viewing more details, editing 
or deleting personnel records. 
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Electronic Support Unit Alameda Intranet 



Personnel Details 



LT Todd Hannah 




VY ork Information 




Job Title 


Webmaster 


Department 


Detachment San Pedro 


Work Phone 


() 1234567 ext: 


E-Mail 


thehannahs@thegridjiet 






Address: 


459 Chips Way 
Monterey CA 93955-5000 


Home Phone 
Beeper #; Cell Phone 


(408) 6580989 


Administrative 




Leave Requested 





SSN: 544699911 



edit this record . 

^ Add new -personnel 



Fill out an online leave form 7 ?: J^^S ^elete feis record ,^ ^ 



> .i ■■ - ' 



;i;Jefr^l) 

Lookup Person 



~3 



Persoonei Admimstratum Database 






liii 



Figure 8.6 Personnel Details 

c. Lookup Personnel Details: The main detail page provides more in depth detail 
of each person in the database. This page is accessed either by following the "details" 
link from the Personnel Database Welcome Page or by using any of the personnel lookup 
boxes found throughout the application. 
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Electronic Support Unit Alameda Intranet 



Update or Edit Personnel Details 

Rank Rate First Name MI 



Last Name 



SSN 

^54469991 1 



^Vork Infomation 


Job Title 


1 Webmaster 


Department 


Detachment San Pedro ^ 


Work Phone 


1234567 ext; 


E-Mail 


thehannahs@thegrid.net 


[Home Information | 



Address: 

Street 



459 Chips Way 



City, State, Zip [Monterey 



'|CA 193 955- 5000 



Home Phone |408 {6580989 
Beeper# 15675678 



Update Data I Reset 



fill out an online leave form 


delete this record 




|BakerJeff^(ETl) 




‘Add new personnel 


Linkup PeBOB j 


Personnel Administration Database 



Figure 8.7 Edit Personnel Details 

d. Edit or Update Personnel: This page allows users to edit or update their own 
record. It contains all of the same information found in the Lookup Details Page, but 
with text boxes available to submit updates. The Social Security Number (SSN) field is 
not updateable because that is the unique identifier, or primary key, of the database. If 
the SSN number is changed the record is essentially deleted. 
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Electronic Support Unit Alameda Intranet 




Add new Personnel Record 

Rank Rate First Name* MI Last Name* SSN* 

p— 3i — I n 1 “ 



Work Information 



Job Title 






Department* 




yr 


Work Phone* 


|408 


1 _ext:l 


E-Mail 


me@esu.alameda.cg 


Home 


Addrp^Q* 






street 






City, State, Zip 


1 1^1 



Home Phone* | 






Beeper # | 




1 Administrative Information 


Intranet Username* 


user 


Intranet Password* 


A*** 



Confirm Password* |**** 

* required fields 

Add New Personnel 1 1 Reset 




Figure 8.8 Add New Personnel On-line Form 
e. Add New Personnel On-line Form: This page is the form used to enter new 
personnel into the database. An Intranet username and password may also be assigned at 
this time. The default security access level on a new username is "user". 
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Electronic Support Unit Alameda Intranet 



Successful Update to Personnel Details 

LT Todd Haimall SSN: 544699911 




Work Information 



Job Title Intranet Application Designer 



Department Detachment San Pedro 



Work Phone 
E-Mail 

Address: 



() 1234567 ext: 
tliehannalis@thegrid.net 

459 Chips Way 



Monterey CA 93955-5000 
Home Phone (408) 6580989 

Beeper #; Cell Phone 5 67 5 67 8; 



Administrative 



Leave Requested 



Rnished. Proceed to Home Page 



Figure 8.9 Successful Update to Database 
f. Successful Update to Database: This page confirms that data was 
successfully entered into the database. A similar page is displayed after every successful 
submission of data to the Intranet databases. 
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Microsoft Internet Explorer 



Deletion is a permanent action. 

( • \ Records should ONLY be deleted by authorized personnel. 



An email will automatically be sent to the record’s owner 
to inform them when a record has been deleted. 




Figure 8.10 Warning Box for Deleting Records 




ENS Joe George 



Vork Information 



Job TiUe 

Department COTR Branch 

Work Phone 0 1 2345 67 ext: 

E-Mail thebaimahs@thegridjiet 



Home Information 



Address: 99 Broadway 

NewYorkCA 10004 
Home Phone (408) 9999999 

Beeper #; Cell Phone ; 



Administrative 



Leave Requested 




Cancel 



Figure 8.11 Delete a Record 

g. Delete Records: Deleting information is handled with caution throughout the 
Intranet. First, the user must be logged in at an appropriate security access level. In the 
Personnel Application, the user must be logged in at security access level "sec admin" to 
even get to this page. When this page is called, a Warning Box (Figure 8.10) is 
immediately displayed. The user must click "OK" to continue. In order to perform a 
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deletion, the user must click on a large red button. Email is automatically forwarded to 
the record's owner informing them of the deletion. 
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E. 



LEAVE APPLICATION 



1. Introduction 

The purpose of the Leave Application is to provide better tracking of personnel 
for the ESU Command and its members. This application addresses one of the 
Command's top goals as identified during the Analysis Phase. Users who have logged in 
at security access level "user" have full access to the Leave Application. Full access 
allows users to view, add, update and delete records. 




Figure 8.12 Leave Admin Application Navigation Structure 



2. Web Pages of the Leave Application 

a. List of Web Page Figures: The following table lists the names of the Web 
pages of this application and the corresponding figure numbers. 



Web Page 


Figure 


Home Page (with Leave Application highlighted) 


8.14 


On-line Leave Request Form 


8.15 


Leave Approval Chain 


8.16 


Status of Pending Leave Requests 


8.17 


Summary of Leave Information 


8.18 


Details of a Leave Request 


8.19 


Past Leave Archive 


8.20 



Figure 8.13 Table of Web Pages and Corresponding Figures 
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f I irrh^gf 



I iMSJrt li^ 

E&rdui'i^ 



£SU Picmc Today! details; 




Electronic Support Unit Alameda Intranet 



Welcome admin . Yon arc lo^ed in with jecnrl^ le ^ 

General Announcements * Personnel on Leave Today 



Po»l(>i] bv I Name 



Farms, Toad McClain, Chuck (ETC) 

QJTJO ) , Rauschkolb, Mark (TTZ) 
4/6/98 

' Post a New Aonouncemeri ""-i' *' ' - 



Leave Period ends oir 



4/15/98 after? days, 
5/1/98 after 24 days. 



Leave Summary 



Secmity 









: AUo«w tor ic9^ to atesdtd&x i 

ESUmgibep.o^dy: YontMUST kigja to- 
■" /- 'hevt teciait'to d»Uib»e», - ; 

















0£Rs/MmHks Bne in the next 51 

- Whose Mari^lare Dne 

^ck b^e tp see the names . ' 
andslatus ofpeoplcwbose 

-s*'' <-marks,are dIer-.-^.,l,^^r.-c 



Personnel TAD Today 

r V, / v';. v; -'f; ' 



;^d,.ScottCrC2) 
irdson, Patni (jjl) 



TAD V.1ie» 

iiTilil 



5/10/98jUSCQCI^^ 
4/9/98 IOC Yo^ 







Plunofthe.Week ■'/ ' -■.1^ 



Tbd^g4/6/98 y 






Figure 8.14 Home Page with Leave Application Highlighted 
b. Home Page: The Leave Application is highlighted here on the Home Page. It 
shows the user which personnel who are away on leave for the day. 
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Electronic Support Unit Alameda Intranet 



Online Leave Request Form 



N am p |DooIittle, Doctor (LT) ^ * 



Leave Address: 
Street* 

City, State, Zip * 
Leave Phone * 



Mayheait L ane „ „ _ 

[Monterey ___ |CA_ 

1^9 !?? 9-0000 _ 



Begin Leave * (mm/dd^) 
End Leave * 

Number of Days on 
Leave 

Reason for Request 




My e-mail address is: 
First Approval 
Second Approval 
Final Approval 






thehannahs@th eg rid.ne t 



DARDIS, DEAN (LT) V 
Hannah, Todd (LT) 
[Executive Oflhcer (XO) ^ 



Submit Leave Request 



Reset 



* Required Fields 



When this form is submitted, an email notification of your leave request will be sent along the approval 
chain of command 



Can*t find yom' record? Click Here to Add New personnel to the database* 



- Currently on L^ave. 



Review; Aporove/Deny 
Peps 1.jaq, L^:Pffl!j^ s: i s - 
(restrfctBd access) 



Status of AH Peodiog 
Leave RequesL 



Past Leave Archrve 



Online Leairo Request 
Fohn 



Figure 8.15 On-line Leave Request Form 
c. On-line Form Leave Request: This page is a form for a user to request leave. 
The information is entered into the database for action. 
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Electronic Support Unit Alameda Intranet 




Review Pending Leave Requests 



Access v - Only make a selection in the block that yon are Approval Authority for. Each person in the approval chain will review 
; ‘ : > these requests and click the Submit button for each individual request that is reviewed.. This is like a signature so don't 'sign* someone 

^ ^ . elses name m another block (i. e. Only select Submit in the Final Approval blodc if you are the Final /qjprovaJ Authority) 



\ Name 


WTien 


Wlty 


Immediate 

Supervisor 


Department Head 


Final Approval 



ETCMcClnin 4/6/98 To visit mom. ETC Hamlin LTDARDIS LCDR 

Hernandez 



thru 4/1 5/98 for 7 days leave 



Click fafcre to view more details 
about ias Leave Request 



approved approved 

Not Yet 
Reviewed 



r Approved r Approved fFj Approved 

r Disapproved r Dis^proved r Disspproved 

[ SiAmit I Submit | | 



Name 


Wien 


Why 


Immediate 

Supervisor 


Department Head 


Final Approval I 


TO Ramchkolb 


4/6/98 

thru 5/1/98 for 24 days leave 


To vacation vnth my 
son 


ETC Hamlin 


LT Keyes 


LCDR 

Hernandez 


















Not Yet 
Reviewed 


Not Yet Reviewed 


Not Yet 
Reviewed 


CEdc here to view more details 
about this Leave Reauest 






c Approved 
r Dis^proved 


c Approved 
r Dis^proved 


c Approved 
r Disapproved 








1 Submit 1 


Sub^ 1 


Submit 1 



Figure 8.16 Leave Approval Chain 

d. Leave Approval Chain: Supervisors may review, approve, or deny on-line 
leave requests in this area. The page is restricted to supervisors by security level. 
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Status of Pending Leave Requests 






Not Yet Reviewed Leave Requests 








Name 


Leave Period and Immediate Supervisor: 

Duration Status 


Department Head: 
Status 


Final Approval: 
Status 




Reagen, Danielle 
(ABC) 


4/8/98 thru 4/1 0/98 for LTJG Rausch 
2 days leave 


LTBenhart 


LCDR Hernandez 


details 

APPROVE 

delete 




Not Yet Reviewed Not Yet Reviewed 


Not Yet Reviewed 


Approved Leave Requests 








Name 


Leave Period and Immediate Supervisor: 

Duration Status 


Department Head: 
Status 


Final Approval: 
Status 




Doolittle, Doctor (LT) 


5/1/98 thru 5/15/98 forLTPife 
15 days leave. 


LTBenhart 


LCDR Hernandez 


details 

APPROVE 

delete 

details 

APPROVE 

delete 

details 

APPROVE 

delete 


McClain, Chuck (ETC) 


approved 

4/6/98 thru 4/1 5/98 for ETC Hamlin 
7 days leave. 


approved 

LTDARDIS 


approved 

LCDR Hernandez 


Rauschkolb, Marie 

cm) 


approved 

4/6/98thru 5/1/98 for ETC Hamlin 
24 days leave. 

Not Yet Reviewed 


approved 

LT Keyes 

Not Yet Reviewed 


approved 

LCDR Hernandez 

approved 


Disapproved Leave Requests 








Name 


Leave Period and Immediate Supervisor: 

Duration Status 


Department Head: 
Status 


Final Approval: 
Status 




Seagar, Bob (AD2) 


4/7/98 thru 5/1/98 for ETC Hamlin 
23 days leave. 


LT Keyes 


LCDR Hernandez 


details 

APPROVE 

delete 




disapproved 


disapproved 


disapproved 



^ PyidtPfl 'StalusofAJl Pending Leave « , .,■ 4- ^ 

Gtgreniiv an Leave imwRprtrtxav (restrttKl _ ' - — " ' ' ' Past Leave Archive • ' Online 1 j;ave Reauest Form 



Figure 8.17 Status of all Pending Leave Requests 
e. Status of Pending Leave Requests: This page contains the current approval 
status of all leave requests entered in the database. 



88 
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Summai’y of Personnel Leave Information 

Currently on Leave (approved) 



(Name 


Leave Period and Duration 




McClain, Chuck (ETC) 


4/6/98 thru 4/1 5/98 for 7 days leave 


details delete 


Rauschkolb, Mark (TTZ) 


4/6/98 thru 5/1/98 for 24 days leave. 


details delete 



Requested Current Leave (not yet reviewed or denied) 



Name Leave Period and Duration 



Planning to Begin Leave within the Next 30 Days 



iName 


Leave Period and Duration 




Doolittle, Doctor (LT) 
Seagar, Bob (ADZ) 


5/1/98 thru 5/1 5/98 for 15 days leave. 
4/7/98 thru 5/1/98 for 23 days leave. 


details APPROVE delete 
details APPROVE delete 



Planning to Begin Leave Over 30 Days from Today 



Leave Period and Duration 



- 1 Status of Ail Pcndiffl! 

onstage | Rm0|iTq — t^aTORemiBst 

- - ■ ' ■ . Xresti-tetBd access) ; 



i Status of AB Pending r - , . ^ Onlim Leave Request 

l Pa^:Leave Archive =— — ^ 

, , irestrttEd access) - . . - 



Figure 8.18 Summary of Current and Upcoming Leave 
f. Summary of Leave Information: Users may check up on the status of their 
own leave requests or see others at this page. The application displays who is currently 
on leave, who will be on leave and contains an archive of who was on leave. Users may 



also follow links to view, edit or delete details of their requests from here. 
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Details of lt Doolittle's Leave Request 


LT Doctor Doolittle 




Leave Address: 






Street 


Mayberry Lane 
Monterey 




City, State 


,CA 




Leave Phone 


(888) 888-8889 




Begin Leave 


5/1/98 




End Leave 


5/15/98 




Number of Days on Leave 


15 




Reason for Request 


To tend the sheep 




e-mail address is: 


thehannahs@thegrid.net 


Approval Status 


First Aq^proval 


LTFife 


approved 


Second Approval 


LTBenhart 


approved 


Final Approval Authority 


LCDR Hernandez 


approved 


— -P W ^ 



CurreiidY-.on Leave Pendina Lea/e Recsjests 
^ : . _ :(restrictal.acc8$sx - Request 



Past Leave Archie Request 



^ Form ... <5 



Figure 8.19 Details of a Leave Request 
g. Details of a Leave Request: This page displays the details of a leave request 
in the database. 
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This archive displays all leave taken one year from todays date. Today is 5/13/98. 



One Year Leave Archive by Last Name (View by Date) 



[Name 


Duration 


Began Leave 


Leave Ended 


Benhart, Ralph (LT) 


1 days 


1/1/98 


1/2/98 


McClain, Chuck (ETC) 


7 days 


4/6/98 


4/15/98 


Reagen, Danielle (AEC) 


2 days 


4/8/98 


4/10/98 


Seagar, Bob (ADZ) 


23 days 


4/7/98 


5/1/98 


Weeks, Steven (ETC) 


7 days 


3/28/98 


4/5/98 



Back to too 



One Year Leave Archive by Date (View by Person) 



[Leave Ended 


Began Leave 


Duration 


Name j 


5/1/98 


4/7/98 


23 days 


Seagar, Bob (AD2) 


4/15/98 


4/6/98 


7 days 


McClain, Chuck (ETC) 


4/10/98 


4/8/98 


2 days 


Reagen, Danielle (AEC) 


4/5/98 


3/28/98 


7 days 


Weeks, Steven (ETC) 


1/2/98 


1/1/98 


1 d^s 


Benhart, Ralph (LT) 


Back to too 









Figure 8.20 Past Leave Archive 

h. Past Leave Archive: This page displays the names of all personnel who have 
taken leave over the past year. The archive is sorted both by name and by date. A similar 
archive page is used for the TAD Application, the Announcements Application, and the 
Supply Application, 
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F. 



TAD APPLICATION 



1. Introduction 

The purpose of the TAD Application is to provide better tracking of personnel for 
the ESU Command and its members. This application addresses one of the Command's 
top goals as identified during the Analysis Phase. Users who have logged in at security 
access level "user" have full access to the TAD Application. Full access allows users to 
view, add, update and delete records. 




Figure 8.21 TAD Application Navigation Structure 



2. Web Pages of the TAD Application 

a. List of Web Page Figures; The following table lists the names of the Web 
pages of this application and the corresponding figure numbers. Some pages, which were 
included as parts of the Leave Application, are nearly identical in the TAD Application. 
Screen shots of these pages, such as the Past TAD Archive page, are not shown. 



Web Page 


Figure 


Home Page (with TAD Application highlighted) 


8.23 


On-line TAD Notification Form 


8.24 


Summary of TAD Information 


8.25 



Figure 8.22 Table of Web Pages and Corresponding Figures 
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Figure 8.23 Home Page with TAD Application Highlighted 



b. Home Page with TAD Application Highlighted: The Leave Application is 
highlighted here on the Home Page. It shows the user which personnel who are away on 
leave for the day. 
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Who 



Electronic Support Unit Alameda Intranet 



Online Temporary' Assigned Duty (TAD) Notification Foi'm 
If you are going to be TAD, please fill out this form. 

Fife, Barney (LT) 



Leaving 5/4/98 



Returning 5/10 



WTiere: [USCGC Bittersweet 

(Command 

Name) 

Reason 
for TAD 



To fix the radar. 






Submit TAD Form 



Reset 



Can't find yom- record? Click Here to Add New personnel to the database. 



CuTT^t acid Upcotima TAD - TAD Notificafiim Form * ^ Past TADArctave 

Figure 8.24 On-line TAD Notification Form 
c. On-line TAD Notification Form: This page is a form for a user to notify the 
Command that they will be away TAD. The information is entered into the database. 
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Summaiy of TAD Infoi'mation 

Currently TAD 



iName 


TAD Period Where Reason 




Byrd, Scott (TC2) 
Fife, Barney OLD 


4/6/98 thru 5/1 0/98 USCGC RELIABLE Fix the radar 
5/4/98 thru 5/1 0/98 USCGC Bittersweet To fix the radar. 


details delete 
details delete 



Planning to Begin TAD within the Next 30 Days 



Name TAD Period Where Reason 



Planning to Begin TAD Over 30 Days from Today 



Name TAD Period Where Reason 



Wallace, Tony 
(GS9) 



6/8/98 thru 6/1 0/98 NPS 



2 day seminar on 

Intranets 



CurreS^d Upcoming TAD ' TAD Notification Fonn ...,^1 Past TAD Archive 

Figure 8,25 Summary of TAD Information 
d. Summary of TAD Information: The application displays lists of personnel 
who are currently TAD and who will be TAD in the future. Users may also follow links 
to view, edit or delete details of their notifications from here. 
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G. ANNOUNCEMENTS APPLICATION 



1. Introduction 



The purpose of the Announcements Application is to provide better 



communications throughout the ESU. It also empowers employees to make broadcast 



announcements instantly. 




Figure 8.26 Announcement Application Navigation Structure 



2. Web Pages of the Announcements Application 

a. List of Web Page Figures: The following table lists the names of the Web 
pages of this application and the corresponding figure numbers. The application also has 
pages for updating announcements, deleting aimoimcements and viewing a past 
announcement archive. Screenshots of these pages are not provided because they are 
similar to the ones from other applications. 



Web Page 


Figure 


Home Page (with Aimoimcements Application highlighted) 


8.28 


Announcements Details 


8.29 


On-line Announcement Form 


8.30 



Figure 8.27 Table of Web Pages and Corresponding Figures 
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Welcome admin . You are logj 
Genei’al Amiomiceinents 


*ed m with security level admin 

Personnel on Leave Today 


[Aimoimcement Posted by | 


|Name Leave Period ends on: | 



Picnic Today! 1400 details 



Benhart, 
Ralph (LT) , 
5/4/98 



Post a New Announcement 



Security 



Intranet Login 


AIbws for «cce« to pag?$ intended i 
forESU menibers only. You MUST j 
bg^ to have access to datebases. | 


Username: 


user j 


Password:; 


|: 




wm 


«■ ' , i 






Doolittle, Doctor (LT) 5/ 1 5/98 after 1 5 days 

Leave Sunmiarv 

Personnel TAD Today 



Name 


TAD 


Where 




until 





Byrd, Scott (TCZ) 5/1 0/98USCGC RELIABLE 

.. , , L.; TAD Summary ■' 






Figure 8.28 Home Page with Announcemeats Application Highlighted 
b. Home Page with Announcements Application Highlighted: The 

Announcements Application is highlighted here on the Home Page. This is where the 
announcement headline is broadcast. A person follows the link for more details of an 



announcement. 
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Announcement Details 



Details oftliat aimouucemeiit are as follows: 



Headline: 

Details: 



Piciiic Today! 1400 

Hie ESU Picnic will be held on the front lawn at 1300. Volleyball net will be 



Posted on: 
Post expires; 



available, 

5/4/98 

5/5/98 



Point of Contact: Benhart, Ralph (LI) 

" Post a New Amolmc’ement ' ’ L View Past Atmovincement i^clwe Delete tbii’Announcement *”*^' 

Figure 8.29 Announcement Details 
c. Announcement Details: This page contains further details of the 
announcement headline posted on the Home Page. 
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Add a new Announcement to the Home Page 




These announcements are for general all-hands broadcast and will be visible to ANYONE visiting the ESU 
Alameda Home Page. Bear this in mind when making a post and keep it professional. Any validated ESU 
Alameda Intranet user may post announcements. 



Point of Contact 



[Benhart Ralph (LT) ^ 



Date of post 



5/4/98 



Date post e:q>ires and removed from 
Home Page 



|5/5/98 



Announcement Headline for Home 
Page: 

(Please limit to one or two lines without carnage 
returns.) 



Picnic Today! 1400 






Details of Aonauncement: 

(Only headline visible on Home Page. Details 
upon folowmg hyperlink No carriage returns.) 



The ESU Picnic will be held on the 
front lawn at 1300. Volleyball net 
will be available. 



■3 



Post Announcement to ESU Alameda Home Page 



Post a New Announcement " ' Past AnnouncemenTArchive 

Figure 8.30 On-line Announcement Form 
d. On-line Announcement Form: This form is used to post an on-line 
announcement. Anyone in the Command who has logged on to the Intranet is able to 
broadcast an announcement using this form. 
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H. PERSONNEL REPORTS APPLICATION 



1. Introduction 

The purpose of the Personnel Reports Application is to provide better 
communications throughout the ESU. It contains reports for information the ESU 
Command considers vital. 




Figure 8.31 Personnel Reports Application Navigation Structure 



2. Web Pages of the Personnel Reports Application 

a. List of Web Page Figures: The following table lists the names of the Web 
pages of this application and the corresponding figure numbers. 



Web Page 


Figure 


Recall Log 


8.33 


Department Phonebook 


8.34 


Alphabetical Phonebook 


8.35 


Marks Due this Month 


8.36 


Status of all Marks Due 


8.37 


Complete Marks Schedule 


8.38 


Edit Marks Schedule 


8.39 



Figure 8.32 Table of Web Pages and Corresponding Figures 
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Recall Log 

Work Phone & E-Mail Listings - AlT)habetical Work Phone & E-Mail Listings - by Department 



Recall Log is FOR OFFICL4L USE ONLY 



iName 


Address 


Home Phone# Beeper# 1 


Baker, Jeff CETl) 


Mulberry Way, Alameda(CA) 


(408) 8768768 


Bartlett, Rex (ETC) 


Friar Tuck Lane, Alameda (CA) 


(408) 980909 


Benhart, Ralph (LT) 


3568B Jurrasic Park Ave., Montere 3 r(CA) 


0 6588958 


Bennett, Darvin (SKC) 


Stourport Av, Alameda(CA) 


(408) 8768768 


Brewster, Punkies (AM2) 


20 Punky way, Seaside(CA) 


0 3938444 546654564 


Byrd, Scott CTC2) 


,(CA) 


(408) 


Cantu, Edward CIT3) 


thers, (CA) 


(408) 


Clarke, Brian CTCCS) 


,(CA) 


(408) 


DARDIS, DEAN (LI) 


222 RAMAGEN DR, GULA GULA (CA) 


(408) 3932563 


Doolittle, Doctor (LT) 


Animal Way, Pacific Grove(CA) 


(408) 6582074 



Figure 8.33 Recall Log 



b. Recall Log: The Recall Log is used to display the home addresses and phone 
numbers of ESU personnel. Its primary purpose is, in case of a general recall, for the 
duty officers to be able to locate personnel who are off duty. 
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Phone & E-Mail Listings - by Department 




Hi ■ Click Here for Phone & E-Mail Listings - Listed Alnhabeticallv 


ElacttowcSwtwosBrtitfh IRM Branch CXJTRBranch' ' ESUBttnaewSarvicwBww 


DgtachBffktOaBd gffiriBgfrdSom? Qlkr DetackwuLSanD^ 


Commanding Officer: woit Phone # 




email 


Lane, Ed (CDR) 


(510)437-3923: 




thehannahs@ihe gri d net 


Executive Officer: 








Hernandez, Mark (LCDR) (510)437-3921: 




thehannahs@lhe gri d net 


Electronic Systems Branch 






Name 


Job Title 


Work Phone # 


email I 


DARJDIS,DEAN(LI) 


DEANER OF WINNERS 


(408)393-1404: 


thehannahs @thegn d net 


Jackson, Carol (ASM3) 




0 1234567. 


thehannahs @the gn d net 


Joes, Stalin (CDR) 


Dictator 


(408)79698:8970 


thehannahs @thegn dnet 


Olsen, Chris (CW02) 


Vessels Section (WHEC, WMEC, ,. 4 ; , “jqi-j. 

WLB) >(510)437-3913. 


thehannahs @the gri d net 


Rausch, Nathan (LTJG) 


Elec Sys Branch Chief 


(510)437-5351: 


thehannahs@the grid net 


Reagen, Danielle (AEC) 




01234567: 


thehannahs @the grid net 


Reichert, Tracy (ET2) 


Pipeliner Si^erviser / DGPS 


(510)437-5894: 


thehannahs @the gn d net 


Smith, Malcom (LTJG) 




01234567. 


thehannahs@the gn d net 


Stokes, John (LI) 


Kodiak IRM Branch Chief 


(408)1211234: 


thehannahs@the gn d net 


Welden,John(CW04) 


Shore Section (WPB) 


(510)437-3795: 


thehannahs @the gn d net 


Back to Ton 








IRM Branch 








Name 


Job Title 


Work Phone # 


email | 



Byrd, Scot±CTC2) 
Cantu, Edward CIT3) 
Clarke, Brian CTCCS) 
Enberg, Melvin CTCl) 

Fnntflinp T^#>unp^T^^ 



RSM 
IT Shop 

D 1 1 Frequency Manager 

RSM 

TT Shnn 



007) 839-6109 
(510)437-3290 
(510)437-5305 
(415)399-3405 
^'5ln^4'^7-3790 



tnehannahs@thegrid.net 
thehannahs@thegnd.net 
thehannahs@thegnd.net 
thehannahs@the gn d net 
thehannah^@th#>orid npt 



Figure 8.34 Department Phonebook 



c. Department Phonebook: This phonebook is organized by department. If the 
departments change, the phonebook structure will change dynamically. For example, 
users may add new departments to the database and the phonebook will update itself 
automatically. It doesn’t need to be redesigned. 
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PhoDe & E-Mail Directory - Alphabetical 



I Click Here for Phone & E-Mail Listings - Listed by Department 

abcdefghijklmnop^rstuvwxyz 



A 



Name 



Job Title 



Department 



Work Phone # 



email 



&5c|^t2lSfi 

B 



Name 



Job Title 



Baker, Jeff (ETl ) TT Shop 



Bartlett, Rex (ETC) 
Benhart, Ralph (LT) 
Bennett, Darvin (SKC) 
Brewster, Punkies (AM2) 
Byrd, Scott (TC2) 



Alt-COTR 

Network Engineer PCS 
Storekeeper 
Tech Support 
RSM 



Department 



ESU Business Services 
Branch 
COTR Branch 
Detachment Oxnard 
Business Services Branch 
Detachment San Pedro 
IRM Branch 



Work Phone # 



(510)437-5668. 

(510)437-3874: 9999 
0 1234567: 
(510)437-5301: 

(515) 1234567: 

C707) 839-6109: 



email 



thehannahs@theend.net 

thehannahs@theend.net 

thehannahs@theerid.net 

thehannahs@theeridnet 

thehannahs@theerid-net 

thehannahs@theerid.net 



Back to Top 

C 



[Name _ Job Title Department Work Phone # email 



Cantu, Edward (IT3) TTShop IRM Branch (510)437-3290: thehannahs@theend.net 

C larke, Brian (TCCS) D 1 1 Frequency Manager IRM Branch (5 1 0) 4 37 -5 3 05 : thehannahs@theend.net 

Back to Top 



Figure 8.35 Alphabetical Phonebook 

d. Alphabetical Phonebook: This phonebook is arranged alphabetically by last 



name. 
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Mai ks Due this Month 



Rank/ Name 
Rate 


Marks Due fay 


Current Status 


XO to Update 
(For XO*s use 


CW02 Hannah, Leesa 


6/1/98 


finished 


Finished 


r 








Not Finished 


a 


AEC Reagen, Danielle 


6/1/98 


Not Finished 


Finished 


r 








Not Finished 




TCCS Clarke, Brian 


6/1/98 


Not Finished 


Finished 


c 








Not Finished 




ATC Robertson, Jill 


6/1/98 


Not Finished 


Finished 


r 








Not Finished 


a 



•Ulxiate' 



lOpdateS 



Marks Due Next Month 



Rank/Rnte Name Marks Due 



AEl Louie, Baby 7/1/98 

AMI Johns, Shem 7/1/98 



Complete Marks ^tus Page 



Marks Due 



Complete OER/Mar!b Schedule ^ ^ \ 



Figure 8.36 Marks Due this Month 

e. Marks Due this Month: This page is primarily for the Executive Officer's 
benefit. It provides the XO with the ability to quickly determine whose marks must be 
completed and when. It allows him to update the status of when the marks were last 
completed. This application addresses one of the XO's top goals as determined during the 
analysis phase. 
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Status of Marks 


Name 


Marks Status 


Date of Last Up±ite by I 
XO 1 


Farms, Toad (LTJG) 
Farms, df^ (LTJG) 
Farms, 653456 (LTJG) 
Joes, Stalin (CDR) 
DARDIS, DEAN (LT) 


finished 


3/26/98 


Lane, Ed (CDR) 


finished 


3/26/98 


Welden, John (CW04) 


finished 


3/26/98 


George, Joe (ENS) 


finished 


4/1/98 


Hannah, Leesa (CW02) 


finished 


5/4/98 


Baker, Jeff 0 


Not Finished 




Bartlett, Rex (ETC) 


Not Finished 





Figure 8.37 Status of All Marks Due 



f. Status of all Marks Due: This page displays the status of everyone's marks. It 



also indicates the date when the last update occurred. 
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Enlisted Marks and OERs Schedule by Date Due (view by Rank/Rate) 



1 Rate/Rank 


Marks are Due by 




Seamau (£2) 


1/1/98 


edit 


Seaman (El) 


2/1/98 


edit 


LTJG (02) 


2/1/98 


edit 


LCDR(04) 


3/1/98 


edit 


LT (03) 


3/14/98 


edit 


CDR (05) 


4/1/98 


edit 


CW04 (CW04) 


4/1/98 


edit 


Seaman (E3) 


5/1/98 


edit 


ENS (01) 


5/1/98 


edit 


CW03 (CW03) 


5/1/98 


edit 


CAPT (06) 


5/10/98 


edit 


Chief Petty Officer (E7) 


6/1/98 


edit 


CW02 (CW02) 


6/1/98 


edit 


First Class Petty Officer (E6) 


7/1/98 


edit 


CWOl (CWOl) 


7/15/98 


edit 


Second Class Petty Officer (E5) 


10/1/98 


edit 


Third Class Petty Officer (E4) 


11/1/98 


edit 


Back to Top 







Enlisted Marks and OERs Schedule by Rank/Rate (view by Date Diae) 



Figure 8.38 Complete Marks Schedule 
g. Complete Marks Schedule: This page displays the dates when a particular 
rank or rate's marks are due. LTJG marks, for example, are due by February 1^ according 
to this schedule. 
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Edit Enlisted Marks and OERs Schedule 




Rate/Rank 



CW02 (CW02) 



Marks Currently Due fay 



6/1/98 



Euter New Date Marks are Due by 
(mm/dd/yy) 



Submit 



Return to Review of Marks Due 





Comtjlete Marks Status Page [. 



Marks Due " Complete OER/Marks Schedule 



Figure 8.39 Edit Marks Schedule 

h. Edit Marks Schedule: The schedule of when marks are due can be edited 
using this form. Sometimes the Coast Guard will make changes to the marks schedule. 
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I. 



SUPPLY APPLICATION 



1. Introduction 

The purpose of the Supply Application is to improve the supply ordering and parts 
tracking process. Users may submit on-line Purchase Requests (PRs), follow up on the 
status of their orders, and view a past order archive with this application. 

The Supply Application radically redefines work roles by pushing responsibility 
for Purchase Request status updates back down to the individual who submitted the order. 
This design addresses one of the Commands top goals, to liberate the Storekeeper of the 
tedious and mimdane task of checking up on everyone else's PRs. 




Figure 8.40 Supply Application Navigation Structure 
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2. Web Pages of the Supply Application 



a. List of Web Page Figures: The following table lists the names of the Web 



pages of this application and the corresponding figure numbers. 



Web Page 


Figure 


Supply Database Home Page 


8.42 


On-line Purchase Request Form - Part 1 


8.43 


On-line Purchase Request Form - Part 2 


8.44 


Complete Purchase Request 


8.45 


Warning Box about Assigning PR Numbers 


8.46 


Storekeeper Form to Assign PR Number 


8.47 


Status Log Update Form 


8.48 


Order Marked as Received 


8.49 



Figure 8.41 Table of Web Pages and Corresponding Figures 
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Supply Web Database Application 

Click here to fill ont a New Pnrchase Request Past Purchase Recaiest Archive 



Storekeeper’s To Do List: Outstanding PR's without assigned PR numbers 



Eoate PR Subzoitted Depaitmeut/Bninch 


Nome ofPersouto Contact 


Assign PR number etc. I 


5/4/98 


COTR Branch 


ETC Chuck McClam (562) 732-7271; 
Location; ESU Det San Pedro 


details Assign PR # 


Back to Top 









Crewmember’s To Do List: Outstanding orders are listed by department Individuals vsrho submit PRs are required to 
penodically review their order(s) here and update the status by following link to the PR status log.. 

Efectromc Systeng BiMch IRM.Bnreb CQTR Branch ,gU SnYEg Branch Cfeltthmcat-Qaari gpjflac»dgo.ga Qlki Dg.tflghmgig.S mBf dro. Detcchmeni Son Diego 



Electronic Systems Branch 



1 Name of Person to Contact 


Purchase Request 
Nmnber 


Date of Last Status 
Update 


Click Cor Details Received or Delete 


LT Todd Hannah ( ) 1 2345 67 , Location; 


123123 


5/4/98 


* PR details * Order Received 

* View Status Lov * Delete PR. 

* Update Status Log 


Back to Top 








HIM Branch 








1 Name of Person to Contact 


Purcliase Request 
Number 


Date of Last Status 
Update 


1 Click for Details Received or Delete 


GS7 Brenda Rios (510) 437-5784, Location. ESU 
Alameda 


1231234 


4/7/98 


• PR details * Order Received 

* View Status Log * Delete PR 



* Update Status Log 



Figure 8.42 Supply Database Home Page 
b. Supply Database Home Page: The Supply Database Home Page presents the 
user with a list of all outstanding Purchase Requests (PR) at the ESU. There is a "To Do" 
list for the Storekeeper which shows all PRs that have been submitted but have not yet 
been assigned a PR Number. The remainder of the page contains ESU personnel "To 
Do" lists, organized by department. Each person who has submitted a PR is required to 
periodically check on the status of the request, with the supply vendor, and update a 
status log. Previously, this information was not available to all employees and the 
Storekeeper had to individually check up on the status of each outstanding PR. 
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Electronic Support Unit Alameda Intranet 



Step 1: Fill out the following initial data for the PR 





1. Name, Phone Number and Branch of Person to Contact 

iLTTodd Hannah ( ) 1234567; Location: 3 

Branch: | Electronic Systems Branch 



Location: |ESU Alameda ^ 

2. Type of Request 
New Request ^ 

A. Additional Infoimabon (Suggested supply sources, etc.) 



Name: [Joes Hardware 










Address [Downtown 










City [Monterey 




State [CA 2ip [93940 






Phone [5555555 ext: j 

5. Approving Officials 

Approving Officials 
(A) 

(1) Autiiorizcd Requisilioncr Name 


Attention: | 

Routing Symbol 
(B) 




Date 

(C) 


Name: |CDR Ed Lcme 

(2) Accounhng Certification Officer 


3 


fxo 


3 




Name: |SKC Darvin Bennett 

(3) Stqjervisor 


[storekeeper 






Name: | LT Barney Fife 

(4) Requester 


3 


[Electronic Systems Branch 


3 




Name: |LTTodd Hannah 

6. Consignee and Destinatioa 
Name: 


.3 


[Electronic Systems Branch 


3 


5/4/98 


[COMMANDING OFRCER, ESU Al^EDA 
Address: 








[bldg 21 RM128 COAST GUARD ISLAND 


±i 






Cijr, lALAMEDA 










State: |CA 2ip: [90000 
Prionty 1 










7. Date Required [ 

8. Government C Yes 

FUnnshed (f mo 


(Pr^^'Sm^Sdey^^ jESU Alameda/Ldl/IPCD 


3 


ims fK. ^tqipons i 

(Cost Center) • 




3 



Submit Inhiat Data - Start a New Purchase Request Form 



Figure 8.43 On-line Purchase Request - Part 1 
c. On-line Purchase Request - Part 1: This is the first half of a Purchase 
Request Form. It contains all the same fields, organized the same way, as a traditional 
paper PR form. 



Ill 




Electronic Support Unit Alameda Intranet 



Part 2: Fill out the Description of Items or Services you wish to purchase. 






ROCUREMENT 

ROCESS 



EQUEST 

APIDLY 



9. Descziptioii of Items or Sendees 

Item or Service 

(Please DONOTpiv«sretaTiiijitiiubqiutbox.Useasin^coAti]iuoiufenleitfe-evei7t]u]kgafter QTY 
a return will not get entntd.) 



Item 

No 



Unit 



Unit Cost 



r~ 


Hammers 


3 

3 


|15 |EA 3 1^00 




Nails 




3 

3 


|15 |dz3 |5.00 


F~ 






3 

3 


1 “ ra r~ 








3 

3 


r~ ra r“ 


F“ 






3 

3 


r“ r“ 






OrderMoreltems 


Submit the Rnal Order | 



Figure 8.44 On-line Purchase Request - Part 2 
d. On-line Purchase Request - Part 2: This is the second half of a Purchase 
Request Form. It contains all fields for ordering up to five items. If the user wants to 
order more than five, they can press the "Order More" button and fill out another five 
items. 
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Electronic Support Unit Alameda Intranet 



The following Purchase Request has been submitted and is now pending For Action: 



ROCUREMENT 

ROCESS 



EQUEST 

APIDLY 



Purchase Request Number 

1. Person to contact: 

2. T^pe of Request: 

3. Orig Office Branch & Location 

4. Suggested Source of Supply 



LT Todd Hannah () 1234567; Location: 
New Request 

Electronic Systems Branch; 

Joes Hardware 
Downtown 

Monterey, CA93940; 5555555 exL 
Attn 



5. A 4 )proving Officials 
Authorized Requistioner 
Accounting Certification Officer: 
Supervisor: 

Requester: 

6. Consignee and Destination. 



7. Date Required 

8. Government Furnished: 



CDREdLane.XO 

SKC Darvin Bennett, Storekeeper 

LT Barney Fife, Electronic Systems Branch 

LT Todd Hannah, 

COMMANDING OFFICER, ESU ALAMEDA 
BLDG 21 RMl 28 COAST GUARD ISLAND 
ALAMEDA, C A 



No 



UnitAJnit Providing LUFS Support 3 0/0/5 A 

Unit/OPFAC this PR Supports 53700 



Item 9. Description of Items or Services 
Number 


Qty 


Unit 


Uidt Cost 




1 Hammers 


15 


EA 


6 


edit 


2 Nails 


15 


DZ 


5 


edit 



Edit Admin Data (1 -8) | Add New Item (9) ^ : Goto Supply Home 



Mark Order as Received 



Fill out Another ^ Bupplv Database Status 

Purchase Request ^ Page . 



Past PR Archive 




View Status Log History 




Figure 8.45 Complete Purchase Request 
e. Complete Purchase Request: This is the page the viewer sees when the final 
PR order has been completed and has been submitted to the database. 
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Microsoft Internet Explorer 



E 




Only the Storekeeper should be Assigning PR Numbers. 

DO NOT ASSIGN A PR NUMBER IF 
YOU ARE NOT AUTHORIZED TO DO SO. 



If necessaiy, go back using the back button 



I OK 



Figure 8.46 Warning About Assigning PR Numbers 



Electronic Support Unit Alameda Intranet 



The following PR will be assigned a PR Number 






Assigne PR Number here: 



Click to Assign PR 



« 



Cancel 



1 . Person to contact: LT Todd Hannah ( ) 1 234567; Location: 

2 Type of Request: New Request 

3. Orig Office Branch & Location ; 

4. Suggested Source of Simply Joes Hardware 

Downtown 

Monterey, CA 93940: 5555555 ext 
Attn: 

5. Approving Officials 



Figure 8.47 Storekeeper Form to Assign PR Number 
f. Storekeeper Form to Assign PR Number: The Storekeeper can use this form 
to assign a PR number to a submitted request once the funding and other administrative 
tasks have been completed. The warning box alerts users that only the Storekeeper is 
authorized to assign PR numbers. 
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Electronic Support Unit Alameda Intranet 



Status Log Updates 



Status Log Update; Updates this PR 



Update Text: 

Updated By: 
Date of Update: 



Joe*s Hardware is still out of hammers. -*“1 

d 

Hannah. Todd (LT) 3 
5/4/98 

Submit Update I Reset! 



or 

Mark Order as Received 




Status Log Update History: History of status Log updates for this PR 



I Date of Update Updated by: Update Text; 



PR# 

Date Submitted 5/4/98 

Point of Contact LT Todd Hannah ( ) 1 234567, Location: 

" Vi^ Status Log History Supply i3at^ase StSSiFPaS^ ~ "p5tPR Pill oiE new Purchase Revest 

Figure 8.48 Status Log Update Form 

g. Status Log Update: The user may use this form to update the database status 
log. On the Intranet, this becomes an individual responsibility. Before the Intranet 
solution, the Storekeeper had to maintain the status updates of all PRs because all the PR 
forms were kept in a paper file folder. By distributing the PR status information across 
the Intranet, the unreasonable burden of tracking everyone's PRs is distributed from the 
Storekeeper to the entire organization. This was one of the Commands top goals. 



115 



Electronic Support Unit Alameda Intranet 



The following PR will be MARKED AS RECEIVED 



Enter the Date the order was received {tprcJ^Aiyy format): p^/98 

I Cancel 



Click to Enter Date Received 



Procurement Request Number: 123123 

1. Person to contact: LTTodd Hannah () 1234567; Location: 

2. Type of Request: New Request 

3. Orig Office Branch & Location 

4. Suggested Source of Supply Joes Hardware 

Downtown 

Monterey, CA 93940: 5555555 ext 

Attn: 

Figure 8.49 Order Marked as Received 

h. Order Marked as Received: This form is used so those individuals may mark 
off when a PR order process has been completed. This removes the PR from the 
outstanding PR "To Do" lists on the Supply Database Home Page. The information is 
recorded in the Past PR Archive page (not shown). 
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J. SECURITY APPLICATION 



1. Introduction 

The Security Application is present throughout all other applications on the 
Intranet. Security is handled on a page by page basis as explained in detail in Chapter 
VII. This section provides screen shots of successful and unsuccessful logins. 



2. Web Pages of the Security Application 



a. List of Web Page Figures: The following table lists the names of the Web 



pages of this application and the corresponding figure numbers. 



Web Page 


Figure 


Home Page with Security Application Login Highlighted 


8.51 


Successful Login 


8.52 


Unsuccessful Login 


8.53 


Access Denied 


8.54 



Figure 8.50 Table of Web Pages and Corresponding Figures 



117 




Electronic Support Unit Alameda Intranet 






Welcome to the ESU Alameda Intranet Site ! As a gUCSt user you may browse any 
pages found under the -’'Extranet" banner in the navigation bar." All information is For 
Official Use Onty. „ , : . . _ - . - ' 

(Please note that you are not currently logged in as a validated ESU Alameda Intranet user and you will not 
have access to internal ESU pages.) ' 



General Announcements i Personnel on Leave Today 




Figure 8.51 Home Page with Security Application Highlighted 
b. Home Page with Security Application highlighted: This is the page the user 
logs into the Intranet from. 



118 










Electronic Support Unit Alameda Intranet 



V Your Login Succeeded! 



You are logged in as; 

Security Session Access Level 



admm 

admin 



Please return to the ESU Home page to begia 

Figure 8.52 Successful Login 



Your Login Failed 



Please return to the ESU Home page to login again or access areas that require no security privileges 

Figure 8.53 Unsuccessful Login 



Electronic Support Unit Alameda Intranet 



You are logged in as 
Security Session Access Level 



You do not have access to that vsreb page. Ihe page you have requested requires for you to log in at a 
Secunty Session Access Level higher than . 




LOGIN: Click here to return to the ESU Welcome p^e where you may Login 



Figure 8.54 Access Denied 

c. Security Login Pages: The top two pages are displayed for either a successful 
or an unsuccessful login attempt. The Access Denied page is displayed when a user 
requests a page that is restricted to a security access level which is higher than what the 
user is logged in at. 
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K. CONCLUSION 



It is difficult to capture the way a software system works by presenting it on 
paper. There are over 80 Web pages on the Intranet and, of course, not all of them were 
presented in this chapter. This section attempted to describe the basic feel and 
ftmctionality of the Intranet with selected screen shots from its applications. 
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IX. IMPLEMENTATION 



A. INTRODUCTION 

The Intranet will be installed at the ESU about six months after the project’s 
initiation. From a technical standpoint, the physical installation is straightforward. The 
implementation process, however, is far more than Just the physical installation of 
software. It involves complex management issues of organizational change leveraged 
through information technology. The final outcome of the implementation process, and 
its impact on the organization, will not be fully imderstood for quite some time. 

The goal of this project is a successful implementation of a new Intranet that adds 
value to the ESU. The minimum definition of success is an implementation resulting in a 
prototype. This basic prototype could then serve as a foundation for future independent 
development efforts. If the implementation is more successful, the Intranet could become 
an operational, working product that would be used daily and maintained, and improved 
locally. 

The Intranet is a powerful, technically sound, well-designed and fully functional 
tool that has the potential to add significant value to the ESU Command. The fact that 
the Intranet is a high quality product, however, does not guarantee its acceptance or use 
throughout the organization. 

Implementation is an organizational wide process of change that will alter current 
lines of communication and business practices. This change has both social and technical 
aspects (Lawrence, 197). The development of the product, up to this point, has focused 



121 



on the technical aspects of analysis and physical design. It is, however, the social aspect 
of the change that determines the final result. 

The implementation process includes both the Implementation and Maintenance 
Phases of the Waterfall Model. This section focuses on the management and change 
issues that are involved, and a formula for change is introduced. The change formula is a 
tool for assessing organizational readiness and a plan of action for change. 

B. IMPLEMENTATION 

The Implementation and Maintenance Phases of the Waterfall Model include 
steps such as installing the new software, preparing the training plan, and establishing the 
long-term maintenance schedule for the new system. These are the technical steps that 
must be taken for any successful system’s implementation. 

The technical steps are essential to a successful implementation, but the social 
considerations are what determine the final outcome. Introducing an information system, 
which radically alters the way people communicate, will have social consequences for the 
entire organization. These consequences, and different ways of seeing and managing 
them, should be considered. 

There is a wide spectrum of possible organizational responses to the new tool. At 
one end of the spectrum, the Intranet could be resisted, completely ignored, and never 
used after the first install day. At the other end, it could be adopted wholeheartedly and 
the ESU could take complete ownership for the system. ESU ownership means they 
would use it daily, maintain it locally, and improve it constantly. There are many reasons 
why the implementation outcome might be somewhere in the middle. Even if the Intranet 
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is simply recognized as a “vision of future possibilities”, the goal of this thesis will have 
been met. 



Increasing Command Investment and Ownership 

► 




Figure 9.1 illustrates the possible spectrum of Intranet implementation outcomes 
and the corresponding organizational reactions to them. In the figure, “functional” means 
some employees use the system. “Operational” means the system is relied upon as a tool 
for the ESU’s daily business. “Owned” indicates a Command investment of resources for 
both maintenance and improvement of the new systems. The spectrum of success 
increases from left to right with a corresponding increase of Command investment and 
ownership. 

In all possible outcomes, the Intranet can serve as one prototype in the Rapid 
Prototyping model of systems development. Rapid Prototyping, as explained in Chapter 
IV, is an iterative process of development. The left end of the spectrum in Figure 9. 1 
corresponds to the early prototypes of the Rapid Prototyping iterative development model 
(see Figure 4.3). The increasing Command investment and ownership of the system 
found towards the right end of the spectrum correspond to more mature prototypes which 
the Command itself could test, revise and enhance to their own requirements. 
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There are many possible reasons why the implementation process might not be 
successful. If old business processes still occur, in parallel with the new Intranet 
methods, confusion could arise. If the new technology is misused by employees who 
perform unauthorized deletions of records or mistaken submission of on-line forms, the 
Command could conclude that the costs of doing business a new way outweigh benefits 
of the old. Resistance to change, a poor maintenance plan, no backup policy, no training 
plan, or no commitment to improving the Intranet are all possible reasons that could also 
lead to a failed implementation. 

The solution to these potential problems is to consider the Intranet 
implementation from a systems thinking perspective. The new Intranet must be 

considered as a dynamic, living entity that must have attention. The databases require 
current, accurate data in order to be relevant. The phone book application database, for 
example, must be populated with accurate phone numbers. The Intranet can not be 
installed and be expected to maintain itself A complete management plan, including 
decisions on who will own the Intranet, who will maintain it, who will enter data, and 
who will use it, must be considered. The new Intranet policy should, at a minimum, 
address security issues, acceptable use instructions, and a backup plan. 

C. STRATEGIES FOR CHANGE 

1. Introduction 

A general strategy for introducing change into an organization includes three 
basic stages. First, the organization must be “unfrozen”. This is when the organization 
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prepares for a change. The leadership should foster an environment that is dissatisfied 
with the status quo. The middle stage is the transition period when the change actually 
occurs. An ideal vision of the future state, after the change has been implemented, should 
be articulated by the change advocates. The final stage is when the change has been 
completed. During this stage, the organization should support and maintain the change. 

The General Accounting Office (GAO) Executive Guide on Improving Mission 
Performance Through Strategic Information Management and Technology describes three 
key processes that the GAO considers critical to introducing an Information Technology 
change to an organization. They are: “(1) deciding to work differently... (2) directing 
resources ... and (3) supporting” (GAO Report, 7). These three processes parallel the 
three stages of unfreezing, transitioning, and supporting change. 

The following section introduces a change formula that is useful for assessing the 
first two stages of introducing change, unfreezing and transitioning. The next section 
introduces the concept of a systems loop. The systems loop describes the possible 
outcome of a change after it has been implemented and is in the third and final stage of 
maintenance and support. 

2. Change Formula 

a. Definition: One way of introducing change is to consider it in the context of a 
formula for change. The change formula, adapted from Professor Michael Beer’s article 
"Leading Change" (p.3. Beer, 1988), can be used to assess organizational readiness for 
change and to implement the change. The change formula, and its relevance to the ESU 
Intranet implementation, is presented below. 
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successful “dissatisfaction with present” X >“cost of 

change = “ideal vision of future” X change” 

“process of change” 

The formula states that there are three critical factors that must be considered for a 
successful change. These factors are multiplied, meaning if one is missing then the whole 
formula is equal to zero, and the change will fail. All three factors must be present with 
sufficient strength to be greater than the cost of change (p.3. Beer, 1988). 

b. Successful Change: Implementation of the Intranet would be a successful 
change for the ESU. The Intranet would add value to the ESU by allowing them to do 
current business processes in a new, more efficient and effective, way. The change could 
be considered increasingly successful as one moves farther to the left on the scale 
presented in Figure 9.1. 

c. Dissatisfaction with Present; Dissatisfaction with the status quo is critical 
because it provides the energy for overcoming organizational resistance to change (p.4. 
Beer, 1988). An advocate of change must be someone who is unsatisfied with the current 
way of doing business and believes that there is a better way. During the requirements 
capture phase of the project, the Command at ESU indicated that there were in fact some 
processes that they would like to see improved. Each of these goals are technically 
addressed with functioning Intranet applications. The Intranet was developed to 
specifically address these problems and issues. 

From a top down perspective, the Command must become the advocate of change. 
The Command can create an environment that is ready for it by insisting on using the 
Intranet applications. Urging employees to do business in a new way will indicate to the 
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rest of the organization that the Command is not satisfied with the status quo. This will 
create an environment that is ready for change. Command advocacy of the Intranet will 
send the signal that is good to use the Intranet. 

If the Command is content with old business processes, in spite of the availability 
of new Intranet solutions, then they are effectively satisfied with the status quo. If the 
Command doesn’t create the environment for change through advocacy, then the rest of 
the organization will not have the incentives to change. 

An environment of dissatisfaction with the status quo can also be fostered from 
the bottom up. If the employees of the organization find that the Intranet is a technically 
soimd solution that has potential to add value to their work, then they are likely to use it. 
The more key personnel who share this idea that the Intranet is useful, or has the potential 
to be of use, the more likely the environment for change will be ready. 

d. Ideal Vision of the Future: Many personnel at ESU must share the “vision of 
what is possible” with a new Intranet. They must recognize it as an improvement over 
the status quo. A sufficient number of key stakeholders must understand how new 
Intranet applications will add value to their daily work. The ESU Command can do this 
by ensuring all personnel have seen the system and are trained in how to use it. 

e. Progress of the Change: The change to using the Intranet will not occur 
overnight. Simply dropping the Intranet into the ESU will not mean it will be adopted 
immediately. The idea must be sold to the employees of the organization who will judge 
the new tool over time. 

The training and demonstration sessions can be used to showcase the merits of the 
system and to gather feedback on ways it can be improved. The Command could appoint 
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various personnel, who are proficient in HTML code, to improve aspects of the system. 
People will become committed to a project that they help create (p.5. Beer, 1988). 

Initially, the physical installation of the Intranet is critical to get right. The first 
few days of its deployment is a crucial time when most people will form strong opinions 
about whether or not it adds value to the ESU. Before it is presented for ESU use, the 
Intranet should be running normally, error-free, on the Web server. If the system is slow 
and inefficient, plagued with frequent crashes or bugs, is difficult to use or has other 
problems that makes its use unpleasant, then it is unlikely people will make any effort to 
fix it. 

f. Cost of Change: Every change has consequences. Although the physical cost 
of building the Intranet was almost nothing, the long-term cost of implementation is more 
significant. The ESU will have to invest resources into the maintenance of the system. 
Someone will have to spend time writing policy on Intranet use, validating the accuracy 
of the databases, and ensuring the Web server is running. Training costs will be incurred 
in order to ensure someone at the Command has a proficiency in administering the Web 
server, authoring Web page code, and possibly even learning how to use Active Server 
Pages. 

The social cost of implementing an Intranet should also be considered. The 
Intranet opens a new avenue of communication across the organization. This new means 
of communication could, for example, have consequences for job roles and positions of 
power. 
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g: Conclusion: All of the criteria of the change formula must be present for an 
environment for change to exist. These factors must cumulatively outweigh the cost of 
the change in order for it to have a reasonable chance of actually occurring. 

3. Systems Loops 

The third and final stage of introducing a change is the support and maintenance 
phase after the change has occurred. It is anticipated that the introduction of the Intranet 
will be met with initial enthusiasm and excitement at the ESU. Since it is a technically 
sound product, the Command is likely to realize the potential the new system has to add 
value to the organization. The excitement is likely to generate Command and 
organizational investment in the product, which will in turn lead to growth and use of the 
Intranet. Initially, the implementation is likely to be a success. 

At some point, however, the growth experienced at the beginning will slow. If the 
Command has not heeded the advice about preparing the environment for change 
presented above, then the limits to growth will quickly appear. The slowdown could 
become so significant that eventually everyone stops using the system, marking the end 
of the value it can add to the ESU’s daily operations. 

This process of growth and then slowing will almost certainly happen at some 
point during the implementation process. The only question is if it will happen sooner 
rather than later. The key principle for the Command to consider is that removing the 
factors that limit growth will delay the eventual slowing. 
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Systems Diagram of 




Figure 9.2 Limits to Growth System Loop of Intranet Implementation 

This diagram of considering systems as loops of growth and slowing is adapted 
from Peter Senge’s "Limits to Growth" system loop archetype (p.73, Senge, 1990). It is 
presented in the context of an ESU Intranet implementation. The limiting factor is 
represented as a poor maintenance plan, which could lead to system errors, corrupt data, 
or security violations. The consequences of the limiting factor reveal themselves after a 
period of delay. 

D. PHYSICAL INSTALLATION 

The technical aspects of a physical installation are straightforward. The general 
steps were outlined in Chapter VII. On-line documentation regarding setup and 
installation of these commercially available products is extensive. 

The Intranet software requirements must exactly match between the NPS machine 
the Intranet was developed on and the ESU Web server the Intranet will actually be 
deployed on. The ESU had to prepare their Web server with the latest software versions 
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used for the project development. Some upgrades were necessary to host the site. The 
physical installation will occur over the summer of 1998. 

E. CONCLUSION 

There is little doubt that the Intranet is a quality product that can add significant 
value to the organization. Technically, it operates reliably, without errors, and has a 
clean, easy to use design. Unfortunately, successful integration of the Intranet into the 
ESU will not depend on its technical merits. It is the social eispect of the change that will 
determine the final outcome of the implementation process. It may take up to a year to 
accurately judge the final effects of introducing Intranet technologies into the ESU 
Alameda workplace. 
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X. CONCLUSION 



The development effort resulted in a functional, operational Intranet for a USCG 
unit. Commercial development of such a system would cost well into the thousands of 
dollars. 

This prototype for this Intranet is generic enough to be adaptable to almost any 
USCG setting. It provides solutions to business processes that are common at almost all 
USCG units. Applications for up to date phone listings, recall logs, leave requests, 
temporary duty requests, marks schedules, and unit- wide announcements would probably 
be desirable to have at any USCG unit. 

Whether the implementation process for this Intranet leads to an operational tool 
that is used daily, or if the implementation leads to a simple prototype, this thesis has 
been a success. A simple idea has grown into a reality. By following an information 
systems software design methodology, a working product has been developed. Along the 
way the author has acquired technical skills in software development, business analysis 
skills for information systems requirements analysis, and managerial skills for 
implementing an information systems change into an organization. 
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APPENDIX A. ASP APPLICATION - DESIGN AND CODE 



A. INTRODUCTION 

The Announcements Application on-line form is used as example here to illustrate 
the development of an Active Server Pages Web page. An ASP page, ending in the 
".asp" extension, consists of both HTML code and Visual Basic Script. The HTML code 
is mostly accomplished with a visual Web page development tool. Front Page 98 Editor 
in this case. The VB Script had to be written into the page line by line, without the 
assistance of any visual development environment. The VB Script code is shown in 
Figures A.2 through A.4 as comments on the FP98 Editor page. (The real code is inside 
the dark boxes.) 

There are over 80 Web pages on the ESU Intranet. Most of them are Active 
Server Pages. The code for each page takes up roughly five to ten typewritten pages of 
HTML and VB Script. Listing hundreds of pages of code here is impractical, so what 
follows is a look at the code, for just one page, through the visual development 
environment of Front Page 98. 

This ASP page is named "announcements_form.asp". It is an on-line form that 
requests user input and then updates the Announcements database with it. The form is 
spread across three figures because it would not fit on just one page. The basic concepts 
of using ASP to perform these operations are briefly explained. These operations are 
similar throughout all the pages of the Intranet. The 5 pages of HTML and ASP code that 
are behind this visual development are also included. 
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B. FRONT PAGE 98 VISUAL DEVELOPMENT ENVIRONMENT OF 
ANNOUNCEMENTS FORM.ASP 




Figure A.1 View of Intranet in Front Page 98 Explorer 
The entire ESU Alameda Intranet is shown here in the FP98 Explorer window. 
The Announcements Application folder is open. 
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^ FronlPage Editor 



Ei>e £di< Go Insert Fcrmot lools TflbJe Fiome iii^nclcrwr Help 

DcgB 



I (None) ^ [ [(delauItto nQ JT-I I I ^ ^ ^ 






i5B!(7paa!^5:»<Jt<5 ji'<2|;-*'’£Sw tes.aHDiHfH St\ 



|j| General Announcements Form 






Electronic Support Unit Alameda Intranet! 



Comment: include ^ovbs.incO^ 

■Comment: IF Request(''Content_Length")=0 THEN’ SHOW THE FORM^ 



Add a new AnDOuncement to the Home Page^ 



These announcements are for general all-hands broadcast and will be visible to ANYONE visiting the ESU Alameda Home 
Page. Bear this in mind when making a post and keep it professional. Any validated ESU Alameda Intranet user may post 
announcements.1i 



•Point of Contact^ 



m" 



|| <% Do While Not R$.EOF%> ^ 

I Comment: '// Set up connection and run query 

Set ObjDBConnection = Server. CreateObject(”ADODB.Connection’') ♦J 
ObjDBConnection.Open "phonebook" V/ Pre-defined ODBC data source 
SQL = "SELECT rate, FirstName, LastName, SSN FROM PERSON ORDER BY LasiName" 

Set RS = ObjDBConnection.Execute(SQL) 

;»J 

f SELECT BOX -I 

<select SEE='T” NAME="POC"> 

<option> <^/o Do While Not RS.EOF %> </option> 

?<option value="<^^ RS("LastName") & ”, ” &RS(”FirstName”) & " (” &RS("rate") & ")” %> "> <Vo= 
RS("LastName”) & ”, ” & RS("FirstName”) & " (” & RS(”rate") & ”)" %> <% RS.MoveNext%><%Loop 
%>^option> 

<option> <%ObjDBConnection,Close%> </option> 

?^selec^ 



[Date of posit^ 



.Comment: response. write ”<strongxbig>” 
jresponse.write date 
response.write ”</slrongx;/big>'TJ 

.m... 



iDate posit expires ;i [<^*DoteAdd'('”d" , i ,i)a’t] ^ 

[land removed from 
jHomePage^ 



Figure A.2 Announcements Form in FP98 Editor (Part 1) 

The first part of the form is shown here. Using an IF-THEN LOOP, the page 
checks to see if the form has been filled out yet. If it has not, then it displays the 
announcement form. 
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iiAjanoimcement 
Headline for 
[Home Page: ^ 
[ICPIease limit to one 
two lines without 
[oarriage returns.)^ 


«i ! — ►r 


H 




jDetails of 
jAnnoimcement: 

|i(0nly headline visible 
[.on Home Page. 
^Details 

jifollowing Ityperlink. 
jiNo ca^ria^:e retums.)1 


r 

o 1 »r 


n 







i^nouncement to ESU Alameda Home Page 



■Comment: ELSE ' Do the update^ 



■Comment: '// Set up connection and run query ♦J 
Set Conn = Server. CreateObject("ADODB. Connection") 

Conn. Open "announcements" '// Pre-defined ODBC data source 



SQL = "SELECT * FROM Announcements" 

set rs = server. CreateObject("ADODB. Recordset") 

♦J 

' // unlock recordset RS 
RS.LockType = adLockOptimistic ♦J 
♦J 

’ // create and open a new RS 

RS.open SQL, Conn, adOpenKeySet ' openkeyset to navigate and reuse this recordset 
♦J 

' //update the recordset 

'// note die use of AddNew as ALL requests will be new 
♦J 

poc = requestform("poc") 
begin_dale = date() 

end_date = requestfonn("end_date") ♦J 
announcement = requesLform("announcement”) 
details = request form("detai Is") 



Figure A.3 Announcements Form in FP98 Editor (Part 2) 

This is the second part of the form. When the user completes the form and 
presses the submit button, the form is submitted back to itself on this same page. The IF- 
THEN LOOP will detect that data has been submitted and the page will begin processing 
after the ELSE ' DO THE UPDATE statement shown above. 



This form is a typical ASP Web page that collects information from the user. 



inserts the data into an ODBC database, and displays the results. The code used on this 



page is re-usable in the sense that the same general method is used throughout the ESU 



Intranet. 
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RS.AddNew-J 
RS(”poc”) = poc 
RS^Tjcgin^die") = begin_datc ^ 
RS("cnd_dale") = end_date *-> 
RS("aimouncemeiif ') = announcement 
RS(''detaiIs'') = details 
VAIPDATCit-J 
RS. update 
•J 

' Close connection 
Conn-close^ 



Success. 

Your announcement has been posted to the ESU Alameda home page as follows;^ 
Headiine:ij ■ ;pl' ' " I 

i Comment; response, write ("<STRONGxBIG>") 
i response. write announcement 

re^onse. write ("</STRONG></BIG>'')^ ii 

:ibetails:^ jComment: =detailsil 

Po^ed on:ii im i| 



Comment; =begtn^date^ 



iPost expires;^ 


: Comment: =end_date^ 


Point of 
Contact: ^ 


Comment: ^oc^ 

In 



D^n^wR^tuni to 

■Comment: END IF % 













Figure A.4 Announcements Form in FP98 Editor (Part 3) 



The ASP pseudocode for the update is presented below (see Figmes A. 3 and A.4): 

• a Connection object named "Conn" is created with the ODBC datasource 
"Announcements" 

• a variable named SQL is assigned as an SQL statement 

• a RecordSet object named "rs" is created 

• the open method is used on the object "rs" which runs the SQL 

• a new RecordSet is created 

• the RecordSet is populated with the values from the users form 

• the RecordSet is updated 

• the connection is closed 
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c. 



HTML CODE OF ANNOUNCEMENTS FORM.ASP 



The HTML code that is behind the visual development environment of Front Page 
98 is presented below. The Visual Basic Script, used for making the Web page an Active 
Server Page, is highlighted in bold typeface. 

<% 

» *********★★*★★★★★★★*★★*★*★★★★*★★★*★★*★*************★*********★***** 

* * PERSONNEL DATABASE - Announcements 
» ★ 

* * For every page that you want to enable access control, put the 
include 

* * file and this file in the same directory. 

» * Type <! — tinclude file=" . . /LoginCheck. inc" — > 

» * BEFORE the <html> tag (very important) at the top of the page you 

* * want to contol access to. Also include the following script. 

» * 

* * If session ("security”) = "Guest" then 
response . redirect ( ” . . / no|__access . asp" ) 

' * end if 
» ★ 

» ******************************************************************* 

%> 

< ! — #include f ile=” . . /user_access . inc" — > 

<% 

If session ("security”) = "Guest" then 

response . redirect ( "http : / / eg . nps . navy . mil /pro to type/ no^access . asp” ) 
end if 
%> 

<html> 

<head> 

<meta name=”GENERATOR" content=”Microsoft Frontpage 3.0"> 

<title>General Announcements Form</title> 

<meta name=”Microsoft Border” content=”t, default ”></head> 

<body stylesrc=”http : //127 .0.0. l/prototype2/_private/style . htm" 
background=” . ./. . /images/Fleck . gif ” vlink=”#0000FF”>< ! — msnavigation — 
xtable border=”0" cellpadding=”0 ” cellspacing=”0” width=”100%”xtr><td> 

< table border=”0” width=”100%” cellspacings” 0” cellpadding=”0” 
height="45”> 

<tr> 

<td width="121” bgcolor=”#000040” height=”ll” valign=”top”ximg 
src=” . . / . . / images /270 .gif” width=”56” height=”42” alt=”270 .gif (13575 
bytes) ” start=”f ileopen"x/td> 

<td width=”730” bgcolor=”#000040” height=”ll” valign=”middle”xp 
aligns” center ”><bigXfont color=”#FFFFFF” f ace=”Tahoma”xbig>Electronic 
Support Unit Alameda Intranet</bigx/fontx/bigx/td> 

<td width=”148” bgcolor=”#000040 ” height=”ll” valign=”top”Xp 
align=”right ”><img sres" . . / . , /images/hh60 . jpg” width=”58” height=”42” 
alt=”hh60 . jpg (7125 bytes) ”></td> 

</tr> 
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</table> 

</td></tr>< ! --msnavigation--></table>< ! — msnavigation — xtable 
border=”0” cellpadding=”0 " cellspacings "0" width="100%"xtr>< ! -- 
msnavigation — xtd valign=”top"> 

<p><! — webbot bot=”PurpleText " preview=”include adovbs.inc" --><! — 
#include f ile=”adovbs . inc" --></p> 

<pX%IF Request ( ”Content__Length") =0 THEN’ SHOW THE FORM%X! — webbot 
bot="PurpleText " PREVIEW=”IF Request ( &quot ; Content_Length&quot ;) =0 THEN’ 
SHOW THE FORM” --X/p> 

<table border=”0" width="100% ”> 

<tr> 

<td width="100%" bgcolor="#FFFF80"Xp 
align=”center”Xstrong><big>Add a new Announcement 
to the Home Page</bigx/strongx/td> 

</tr> 

</table> 

<p>These announcements are for general all-hands broadcast and will be 
visible to ANYONE 

visiting the ESU Alameda Home Page.  Bear this in mind when making 
a post and keep it 

professional.   Any validated ESU Alameda Intranet user may post 
announcements . </p> 

<form ACTION="announcements_form. asp” METHOD="POST” onsubmit=”return 
Front Page_Forml_Validator (this) " name="FrontPage_Forml”> 

<table border="0” width=”100%” cellspacing=”4 ” cellpadding=”0”> 

<tr> 

<td width=”35%” valign=”top” bgcolor=”#E8E8E8 ”xfont 
colors" #0 00000 ”><strong>Point of 

Contact</strongx/f ontx/td> 

<td width="50%" valign=”top”> 

<% ’ // Set up connection and run query 

Set ObjDBConnection = Server . CreateObject ( "ADODB. Connection") 
ObjDBConnection.Open "phonebook" ’// Pre-defined ODBC data source 
SQL = "SELECT rate, FirstName, LastName, SSN FROM PERSON ORDER BY 
LastName" 

Set RS = ObjDBConnection. Execute (SQL) %> 

<pX? --webbot bo t= "Validation" B-Value-Required="TRUE" B-Disallow-First- 
Item="TRUE" — Xselect SIZE="1" NAME="POC"> 

<option> <% Do While Not RS.EOF %> </option> 

<option value=’’<%= RS ( "LastName") & & RS ("FirstName") & " 

(" & RS("rate") & ") " %> "> <%= RS ( "LastName") & ", " & RS ("FirstName") 

& " (" & RS("rate") & ") " %> <% RS .MoveNext%X%Loop %X/option> 

<option> <%ObjDBConnection.Close%> </option> 

</select> </td> 

</tr> 

<tr> 

<td width="35%" valign=”top" bgcolor="#E8E8E8 "xstrongxfont 
color=”#000000 ”>Date of post</fontx/strongx/td> 

<td width="50%" valign=”top”x%response . write "<strongxbig>" 
response .write date 
response .write "</strongx/big>"%> 

</td> 

</tr> 

<tr> 
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<td width=”35%" valign="top” bgcolor="#E8E8E8 "xfont 
color="#0 00000 "><strong>Date post 

expires and removed from Home Page</strongX/f ont></td> 

<td width="50%” valign="top"xinput TYPE=”text” 
VALUE="<%=DateAdd(”d”, l,Date)%>” SIZE="20" NAME="end_date”> </td> 

</tr> 

<tr> 

<td width="35%" valign="top" bgcolor='*#E8E8E8 "xfont 
color="#0 00000 "><strong>Announcement 
Headline for Home Page: <br> 

</strongXsmall> (Please limit to one or two lines without carriage 
returns . ) </smallx/fontx/td> 

<td width="50%" valign="top"Xtextarea ROWS=”2” COLS="40" 
NAME="announcement "> 

</textareaX/td> 

</tr> 

<tr> 

<td width=”35%” valign="top" bgcolor="#E8E8E8 "xfont 
color=" #000000 "><strong>De tails of 
Announcement : <br> 

</strongXsmall> (Only headline visible on Home Page. Details upon 
following hyperlink. No 

carriage returns . ) </smallx/f ontx/td> 

<td width="50%" valign="top”xtextarea ROWS="4" COLS="40" 
NAME="details"> 

</textareax/td> 

</tr> 

</table> 

<div align=”center"xcenterxpxinput TYPE="submit " VALUE=”Post 
Announcement to ESU Alameda Home Page" NAME="post"> </p> 

</centerX/div> 

</form> 

<pX%ELSE » Do the update%X ! — webbot bot="PurpleText " PREVIEW="ELSE ’ 

Do the update" — ></p> 

<P> 

<%*// Set up connection and run query 

Set Conn = Server . CreateOb ject ( "ADODB . Connection” ) 

Conn. Open "announcements” ’// Pre-defined ODBC data source 

SQL = "SELECT * FROM Announcements" 

set rs = server . CreateOb ject ("ADODB . Recordset") 

’ // \anlock recordset RS 
RS.LockType = adLockOptimistic 

* // create and open a new RS 

RS.open SQL, Conn, adOpenKeySet ’ openkeyset to navigate and reuse this 
recordset 

* //update the recordset 

* // note the use of AddNew as ALL requests will be new 

poc = request . form ("poc") 
begin^date = date() 

end^date = request . form ("end^date") 
announcement = request, form ("announcement") 
details = request . form ("details") 
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RS . AddNew 

RS("poc”) = poc 

RS ( ”begin_date ** ) = begin^date 

RS ("end_^date”) = end_date 

RS ( "announcement”) = annoxancement 

RS ("details") = details 

* //UPDATE it 
RS . update 

* Close connection 
Conn . close%> 

</p> 

<table border="0" width="100%"> 

<tr> 

<td width="100%” bgcolor="#FFFF80"Xp 
align="center"><big><strong><bigXbig>Success . </bigX/bigX/strongx/big 
xbr> 

Your announcement has been posted to the ESU Alameda home page as 
follows : </td> 

</tr> 

</table> 

<table border="0" width="558" cellspacing="4 " cellpadding="0 " 
height="158"> 

<tr> 

<td width="20%" valign="top" height="24 ">Headline : </td> 

<td width="80%" bgcolor="#E6FFE6" valign="top" 
height= ” 24" ><%response . write ( "<STRONGXBIG>” ) 
response . write announcement 
response . write ( "</STRONGX/BIG>") %> 

</td> 

</tr> 

<tr> 

<td width="20%" valign="top” height="21">Details : </td> 

<td width=**80%*' bgcolor="#FFFFFF" valign="top" 
height=" 21" ><%=details%> 

</td> 

</tr> 

<tr> 

<td width="20%" valign="top" height="22">Posted on:</td> 

<td width="80%" bgcolor="#E6FFE6" valign="top" 
he i ght = "22" X%=begin_^date%> 

</td> 

</tr> 

<tr> 

<td width="20%" valign="top" height="25">Post expires : </td> 

<td width="80%" bgcolor="#FFFFFF" valign="top" height="25 "X%= 
end__date%> 

</td> 

</tr> 

<tr> 

<td width="20%" valign="top" height="4 6">Point of Contact: </td> 

<td width="80%" bgcolor="#E6FFE6" valign^"top" height="4 6"><%=poc%> 
</td> 

</tr> 

</table> 

<hr> 
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<div align=**center "><center> 

<table border=”l” width=”35%”> 

<tr> 

<td width="100%” bgcolor=**#COCOCO”xp align="center”xa 
href=” . . / . . /home . asp’’>It * s Done . 

  Return to Home Page</ax/td> 

</tr> 

</table> 

</centerx/div> 

<pX%END IF%X/p> 

<hr> 

<table border="0" width=”100% " cellspacing=”4 ” cellpadding=*’0"> 

<tr> 

<td width="33%” bgcolor="#C0C0C0" align=”center "Xa 
href=*’announcements_f orm. asp"Xsmall>Post 
a New Announcement</smallx/ax/td> 

<td width=”33%” bgcolor="#C0C0C0" align="center "Xa 
href ="past_Announcement_archive . asp"xsmall>View 
Past Announcement Archive</smallx/a></td> 

</tr> 

</table> 

&nbsp ; < ! — msnavigation — x/tdx/trx ! — msnavigation — ></tablex/body> 
</html> 



D. CONCLUSION 

This section was included in order to convey the aspects of programming a typical 
interactive and dynamic Web page using HTML, VBScript and ASP. 
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APPENDIX B. GLOSSARY OF TERMS 



AOR (Area of Responsibility) 

This is the term used to describe the geographic area where a USCG unit works, 
BACK-END DATABASE 

This term is used to describe the database that holds data used to generate pages on an 
Intranet. 

BROWSER 

A Client program (software) that is used to look at various kinds of Internet resources. 

DFD (Data Flow Diagram) 

A graphical display that illustrates business processes and data interfaces from a data 
perspective. 

ESU (Electronic Systems Support Unit) 

A U.S. Coast Guard facility that maintains and supports all facets of Coast Guard 
electronic equipment. 

FTP (File Transfer Protocol) 

A protocol used to transfer a complete file from one computer to another. 
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GUI (Graphical User Interface) 

A GUI replaces the keyboard commands typical of old-fashioned computers with point- 
and-click buttons and menus. 

HOME PAGE 

The Web page that your browser is set to use when it starts up. The more common 
meaning refers to the main Web page for a business, organization, person or simply the 
main page out of a collection of Web pages 

HTML (Hypertext Markup Language) 

The coding language used to create Hypertext documents for use on the World Wide 
Web. HTML looks a lot like old-fashioned typesetting code, where you surround a block 
of text with codes that indicate how it should appear, additionally, in HTML you can 
specify that a block of text, or a word, is linked to another file on the Internet. HTML 
files are meant to be viewed using a World Wide Web Client Browser. 

HTTP (Hypertext Transfer Protocol) 

The protocol used to transport a WWW page from one computer to another. 

HYPERTEXT LINKS 
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Generally, any text that links to another document - words or phrases in the document 
that can be chosen by a reader and which cause another document to be retrieved and 
displayed. 

INTERNET 

The vast collection of inter-connected networks that all use the TCP/IP protocols and that 
evolved from the ARPANET of the late 60’s and early 70’s. The Internet now connects 
hundreds of thousands of independent networks into a vast global Internet. 

INTRANET 

A private network inside a company or organization that uses the same kinds of software 
that you would find on the public Internet, but that is only for internal use. 

LAN (Local Area Network) 

A network of computers that transmits data along a single shared medium in a small 
geographical area (i.e. a single office building or college campus). 

LINK (See Hypertext LINK) 

SK (Storekeeper) 

An enlisted rating responsible for providing and accounting for the constant stream of 
supplies, clothing, commissary items and spare. 
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TAD (Temporary Assigned Duty) 

The temporary assignment of a service member away from the parent command to 
perform duties at a different command. 

TCP/IP (Transmission Control Protocol/Intemet Protocol) 

The collection of transport and application protocols used to communicate on the Internet 
and other networks. 

URL (Uniform Resource Locator) 

An address or location of a site to be viewed on the WWW. 

WEB BROWSER (See BROWSER) 

WWW (World Wide Web) 

Computers which are linked and which provide hyperlinks to Internet resources 
worldwide. 
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